Discover the current executable contract
Start with the deployment’s OpenAPI, agent instructions and directory catalog. MCP exposes the same backend through stateless Streamable HTTP; using a tool interface does not bypass ownership checks or provider requirements. The catalog includes reference destinations that may be paused or outside the service’s implemented scope.
The public product is checked execution for a fixed $49 USD service fee. Signup, repository diagnostics and complete destination preflight are free. Only an eligible, explicitly authorized draft can be paid. No directory count or approval outcome should be inferred from the list of catalog pages.
# Use the deployment you verified, without account credentials.
export MCP_LISTER_URL="https://your-deployment.example"
curl --fail-with-body "$MCP_LISTER_URL/api/v1/directories"
curl --fail-with-body "$MCP_LISTER_URL/openapi.json"Create the account and connect the source owner privately
POST /api/v1/accounts returns a new account and a once-shown API key. Retain the response privately through a secrets-aware client. Email is a contact field, not an account recovery or authentication mechanism. Use X-API-Key for protected requests and for every MPP retry.
Upload provider credentials directly over HTTPS to POST /api/v1/connections from the owner’s secrets store. Later API and MCP calls use only opaque connection IDs. Do not put GitHub, registry or Smithery secrets in chat, tool arguments, manifests or logs. Connections are encrypted, expiring and revocable. Supported GitHub registry namespaces use a fresh registry JWT exchanged at execution; upstream PRs use the operator’s separate contribution identity.
Save the real released software and access model
POST /api/v1/servers saves repository_url, name, description and transport, plus the package or public endpoint and destination-specific fields. A remote server should declare auth_type and actual remote_access. Use public_signup only if anyone can really create an account; private, invite-only and per-user endpoints cannot masquerade as a shared public service.
Smithery initially supports public unauthenticated remote publication. Local awesome-list contributions need a real versioned npm executable and install instructions. Remote awesome-list entries need the exact Glama connector and access requirements. Docker remote contributions depend on configured official validation. Read the source requirements rather than filling every profile field speculatively.
{
"repository_url": "https://github.com/OWNER/REPO",
"name": "Weather MCP",
"description": "Read weather observations.",
"transport": "streamable-http",
"endpoint_url": "https://your-service.example/mcp",
"registry_name": "io.github.OWNER/weather",
"version": "1.0.0",
"auth_type": "none",
"remote_access": "public"
}Run the full free preflight for the selected set
POST /api/v1/preflights binds the profile, requested destinations and connection references into an immutable report. Inspect the global checks and each target’s state, exact public plan, evidence, blockers and remedy. A repository score does not replace these destination checks.
A payable set needs at least one qualifying new submission, no selected blocked or unavailable target, valid owner connections and a capable worker. Existing verified listings are evidence-only. Reports initially expire within thirty minutes; changes to the profile or connections require fresh checks. Disclosed Glama evaluation dependencies can continue within the same launch, but no downstream write occurs until evaluation is observed. The launch follows supported provider evidence for ninety days.
POST /api/v1/preflights
X-API-Key: YOUR_API_KEY
Content-Type: application/json
{
"server_id": "SERVER_UUID",
"directory_slugs": ["official-mcp-registry", "cline-marketplace", "kilo-marketplace"],
"connection_refs": {"github": "OWNER_CONNECTION_UUID"}
}Authorize an unpaid draft, then pay its launch ID
Show the owner the exact destinations and public payloads first. With explicit authorization, POST /api/v1/launches using the preflight ID, authorized_amount matching the saved quote, authorize_submissions:true and a stable Idempotency-Key. That creates an unpaid immutable draft; it does not publish anything.
With separate authority to spend $49, send {launch_id} to POST /api/v1/billing/pay. An actual HTTP402 challenge is answered by an authorized Stripe SPT wallet. Retry the identical body, X-API-Key and Idempotency-Key with the Payment credential. Human Checkout uses the same launch-bound body. Caller prices and coverage overrides are rejected.
POST /api/v1/launches
Idempotency-Key: YOUR_UNIQUE_DRAFT_KEY
{"preflight_id":"APPROVED_PREFLIGHT_UUID",
"authorized_amount":4900,
"authorize_submissions":true}
# After explicit spending authorization:
POST /api/v1/billing/pay
X-API-Key: YOUR_API_KEY
Idempotency-Key: YOUR_UNIQUE_PURCHASE_KEY
{"launch_id":"APPROVED_LAUNCH_UUID"}Payment queues the work; evidence closes the loop
Verified settlement automatically inserts the authorized job set exactly once. The worker rechecks before its first external write, records actual provider identifiers and follows supported status or ingestion checks. The customer does not need to call a manual submit endpoint for each destination.
Read GET /api/v1/launches/:id for queued, running, submitted, awaiting_ingestion, listed, needs_attention or failed jobs. A submitted PR or intake request is proof of the action, not directory approval. A provider-success state must match the intended source or endpoint before listed is reported. Unknown writes are reconciled before retry; mixed outcomes stay visible.
After a payment timeout, query the owned order and launch and keep the original purchase key. Never create a replacement purchase while its outcome is unknown. Browser return pages do not grant fulfillment, and a missing merchant or worker integration must not be described as success.
Sources and scope
Primary documentation checked 2026-10-29. The workflow advice is MCP Server List’s editorial guidance; each destination controls its own current requirements and review.