MCP Server List

Submit to Official MCP Registry

Publish versioned server metadata with a verified namespace. The registry describes packages and remote endpoints; it does not host your application.

Publish an authorized versioned registry record. Eligibility is checked before purchase.

Owner-authorized registry publicationSources checked

What to prepare

  • A valid server.json identity and release version in a supported GitHub namespace controlled by the connected owner.
  • For npm/stdio: an already published executable package whose version, repository and mcpName match the profile.
  • For remote publishing: an accurate public HTTPS Streamable HTTP endpoint and connection metadata.
  • A secure source-owner GitHub connection, passing free preflight, and an available execution worker.

A technical identity for downstream discovery

Choose this target when another client or catalog needs structured connection metadata. Treat the registry name as a durable identifier: keep it in your release notes, package metadata, and submission records. A new marketing title rarely justifies a new technical identity.

The official documentation currently labels the registry as preview. Keep your release process able to regenerate the manifest from source rather than relying on a single copy held by a listing service.

Local package or remote service?

An installable server needs a reproducible package release. A remote service needs a reachable endpoint. These paths can coexist in a manifest, but test each independently: a working HTTP deployment does not prove that a package launches from a clean machine.

For remote submissions, use Streamable HTTP for a new integration and describe authentication without embedding a live secret. The registry documentation treats SSE as a compatibility path for existing clients.

Verify after the publisher returns

Read the registry response for the exact server name and version, then check the public record. Save this evidence separately from your launch plan. Registry publication does not establish that an unrelated directory has imported the record or that a client recommends your server.

mcp-publisher init
# Review server.json and the published package/endpoint.
mcp-publisher login github
# External write: run only after approving the manifest.
mcp-publisher publish

Submission workflow

  1. Save the actual package or endpoint and connect the source owner securely.
  2. Run the free full preflight and inspect the exact manifest, namespace authorization and existing-version checks.
  3. Authorize the checked launch. Verified payment automatically queues publication using a freshly exchanged registry JWT.
  4. Read the exact returned name/version and public record evidence; downstream directory ingestion is tracked separately.

Blockers to resolve before review

Use these as preparation checks. The destination makes its own acceptance decision.

  • The token does not authorize the namespace declared in server.json.
  • The published package lacks the matching ownership metadata or the requested package version is unavailable.
  • The manifest is invalid, the release version conflicts, or required package/remote details are missing.

Primary sources

Checked 2026-10-29. Follow the destination’s current instructions if its requirements change.

← Compare all destinations