Publishing to the Official MCP Registry

The Official MCP Registry at registry.modelcontextprotocol.io went live in preview in late 2025. It is the canonical listing surface for MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft. Publishing there once ripples out to the downstream aggregators — PulseMCP, Smithery, Glama, mcp.so — over the following 24 to 72 hours without additional submissions.

This is the actual sequence we followed to publish Gnosem. It took about 20 minutes end to end, most of which was waiting for DNS propagation.

Prereqs

• An MCP server reachable at a stable HTTPS URL (Gnosem: https://gnosem.dev/mcp).
• A domain you control (Gnosem: gnosem.dev).
• Access to your domain's DNS records — you'll be publishing a TXT record.

You do not need a GitHub repo for the registry itself, but you'll want one for the downstream aggregators (Glama and mcp.so both require a repo URL). A README-only repo is fine.

Step 1: install the CLI

brew install mcp-publisher

Or grab a release from the registry repo. The binary is called mcp-publisher and does one thing: publishes server.json manifests to the registry.

Step 2: write server.json

At the root of your repo, create server.json. The schema is documented at static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json. Here is Gnosem's:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "dev.gnosem/gnosem",
  "title": "Gnosem",
  "description": "Cross-vendor AI memory over MCP. One semantic store, readable and writeable from every MCP client.",
  "version": "1.0.0",
  "repository": {
    "url": "https://github.com/gnosem/gnosem",
    "source": "github"
  },
  "websiteUrl": "https://gnosem.dev",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://gnosem.dev/mcp"
    }
  ]
}

Two things that trip publishers up:

1. Description length. The schema caps description at 100 characters. Ours is 98. Anything longer and validation rejects with HTTP 422.
2. Namespace format. The name follows a <namespace>/<server-name> pattern. If you're publishing under a domain you own (recommended for company-run servers), use the reverse-DNS form: dev.gnosem/gnosem. If you're publishing an npm-distributed server, use io.github.<user>/<package>.

Validate before you publish:

mcp-publisher validate server.json

You want the response ✅ server.json is valid. Any schema errors surface here with the exact field.

Step 3: DNS-verify your namespace

To publish under dev.gnosem/*, you have to prove you control gnosem.dev. The registry does this with an Ed25519 signature attached to a DNS TXT record.

Generate a keypair (keep it out of source control):

openssl genpkey -algorithm Ed25519 -out ~/.config/gnosem-mcp-key.pem
chmod 600 ~/.config/gnosem-mcp-key.pem

Compute the TXT record value:

PUBKEY=$(openssl pkey -in ~/.config/gnosem-mcp-key.pem -pubout \
  -outform DER | tail -c 32 | base64)
echo "v=MCPv1; k=ed25519; p=$PUBKEY"

Publish that TXT record at the apex of your domain (Name: @, Type: TXT, Content: the string above, TTL: 300s so it propagates fast). Confirm via dig +short TXT gnosem.dev @1.1.1.1. When both 1.1.1.1 and 8.8.8.8 return the string, you're ready.

Step 4: login and publish

The publisher expects the private key in hex, not PEM. Convert on the fly:

HEX_KEY=$(openssl pkey -in ~/.config/gnosem-mcp-key.pem -outform DER \
  | tail -c 32 | xxd -p -c 64)

mcp-publisher login dns --domain gnosem.dev --private-key "$HEX_KEY"

The CLI verifies the TXT record matches your public key. On success: ✓ Successfully logged in.

Then publish:

mcp-publisher publish server.json

You get ✓ Server dev.gnosem/gnosem version 1.0.0 and the listing is live.

Step 5: verify

curl "https://registry.modelcontextprotocol.io/v0/servers?search=gnosem" | jq .

You should see your server object with _meta.io.modelcontextprotocol.registry/official.status: "active".

What cascades automatically

Publishing to the official registry feeds these downstream aggregators without further action:

• PulseMCP — daily ingest from the official registry. Listings usually appear within 24 hours.
• Smithery — ingests from the registry and may also auto-scan your MCP endpoint. If your /mcp is Bearer-gated (Gnosem's is), Smithery's scan will fail unless you also serve a /.well-known/mcp/server-card.json containing the same manifest.
• Glama — pulls from the registry plus its own scan. Requires a public GitHub repo linked in repository.url.
• mcp.so — ingests from the registry; may take a few days.

These aren't guaranteed timelines — the aggregators run on their own schedules — but you shouldn't need to submit separately to any of them.

What doesn't cascade

The two big awesome-mcp-servers lists on GitHub — punkpeye/awesome-mcp-servers and wong2/awesome-mcp-servers — do not auto-ingest. Those still require manual submissions: a GitHub PR for punkpeye's list, and a web form at mcpservers.org/submit for wong2's.

If you're publishing your own MCP server, the whole flow above is one afternoon. The tooling is good enough that most of the time is spent waiting for DNS. The registry itself is fast, honest, and doesn't lock you into any vendor.