If you went looking for the "official MCP Registry" expecting an app store — a searchable grid of servers with star ratings, install buttons, and an editor's-pick row — you will be briefly disappointed, and then, if you're the right kind of developer, quietly relieved.

Because the thing that launched at registry.modelcontextprotocol.io on September 8, 2025 is not that. It's an API and a catalog with almost no opinions about what you should install. The interesting decision its maintainers made is what they left out.

What it actually is

The official registry is a canonical, single source of truth for published MCP servers — and not much more. It's open source, community-driven, and backed by an unusually broad coalition: Anthropic, GitHub, Microsoft, Block, and PulseMCP, with maintainers drawn from all of them (Tadas Antanavicius from PulseMCP, Toby Padilla from GitHub, Adam Jones from Anthropic, plus MCP co-creator David Soria Parra). The repo has cleared roughly 7,000 stars.

It is also, loudly and repeatedly, a preview. The launch post is explicit that there are no data-durability guarantees and that breaking changes — or a full data reset — may land before general availability. As of mid-2026 that's still true. Treat it like a public beta you publish to, not a system you build a business on top of yet.

The non-obvious part is the word official. Most people hear "official registry" and assume it means discovery — the place users go to browse. It doesn't. Here, "official" means provenance: a trustworthy answer to "who actually owns this server name, and is this metadata real?" Discovery is somebody else's job, on purpose.

The registry isn't competing with Smithery or Glama. It's the thing they read from.

The spine: you have to prove you own the name

This is the design choice that makes the rest make sense. The open question for any package ecosystem is the boring, vicious one: what stops me from publishing stripe-mcp and walking off with everyone's traffic? npm has lived that nightmare. MCP's answer is namespace-based authentication baked into the publish step.

Server names are reverse-DNS namespaces, and the auth method you use determines which namespace you're allowed to touch:

So provenance isn't a verification badge bolted on afterward. It's the only way in. You cannot publish io.github.someone-else/server because you cannot authenticate as them. That's how the registry structurally resists name-squatting and the tool-poisoning and rug-pull games that thrive when names are cheap. It doesn't deep-scan your code — security scanning is explicitly delegated downstream and to the underlying package registries — but it does anchor every listing to an identity you had to prove.

The publish flow, concretely

Here's the whole thing. Install mcp-publisher (prebuilt binary or brew install mcp-publisher), then scaffold and ship:

mcp-publisher init             # generates a server.json from your project
# ...edit server.json...
mcp-publisher login github     # authenticate to your namespace
mcp-publisher publish          # validate against schema + push

The server.json it produces is small on purpose:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.username/servername",
  "description": "What your server does",
  "version": "1.0.0",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@username/package-name",
      "version": "1.0.0",
      "transport": { "type": "stdio" }
    }
  ]
}

That transport block is where your earlier architecture decisions show up — whether you shipped stdio, SSE, or Streamable HTTP, and whether you offer a remotes endpoint instead of a package. If you haven't built the server yet, start with how to build an MCP server and, for anything hosted, how to authenticate a remote MCP server — the registry assumes those exist; it only records that they exist.

Note: the registry stamps each entry with a stable UUID for durability and your authenticated namespace for provenance. The namespace says who you are; the UUID gives clients a permanent handle even if you rename things.

Where Smithery, Glama, MCP.so and Mastra fit

This is the payoff of keeping the upstream thin. The registry is the source; the directories are the storefronts.

The protocol's own OpenAPI spec is open precisely so anyone can stand up a compatible sub-registry. Publish once, upstream, and the ecosystem mirrors it downstream. (If you're wrangling several of these at runtime, the gateway comparison is the next problem you'll hit.)

So what should you do

If you maintain a server: publish to the official registry first, because most directories are downstream of it. Pick your namespace by the identity you can actually prove. And weigh your SDK choice — the FastMCP vs. official SDK call shapes how cleanly server.json falls out of your project.

If you're counting servers across all these registries, don't — that way lies madness, as nobody can count the MCP servers explains. The numbers double-count across storefronts precisely because they all ingest the same upstream.

The registry's bet is that trust and discovery are different problems, and that conflating them is how app stores rot. Keep the canonical layer boring, provable, and minimal; let a competitive ecosystem fight over the UX. It's a quietly radical decision dressed up as a JSON schema — and, preview caveats aside, it's the most grown-up thing to come out of the MCP world this year.