Skip to main content

Publish Once or Fragment Forever? About the State of MCP Registries

· 7 min read

Grid banner

Introduction​

MCP (Model Context Protocol) is becoming the connective tissue between AI agents and real systems. As servers, gateways, and clients multiply, discovery and trust have turned into the bottleneck. That's why registries matter. In early September, modelcontextprotocol.io announced the MCP Registry (Preview) and a Generic Registry API — a push to standardize how MCP servers are published, discovered, and verified. At the same time a range of parallel registries such as Smithery, Raycast, MCP.so, PulseMCP, and FluidMCP are shaping the landscape with their own approaches — from curated catalogs to productivity-focused directories. In this post, I'll explore the emerging MCP registry landscape: what a registry is expected to do, how the official specification defines "main" and "sub-registries", and how today's parallel registries compare.

GitHub MCP Registry Screenshot
Screenshot: GitHub MCP Registry (github.com/mcp, September 2025)

What an MCP Registry must do​

Every MCP registry, no matter who operates it, is expected to cover the same fundamentals. Without these, discovery quickly turns into chaos and trust evaporates.

Verification​

Trust is the foundation of any registry. The main registry at modelcontextprotocol.io bakes verification directly into the publishing flow: maintainers must authenticate with a GitHub account, via DNS, or use an OIDC token before a server is accepted. That ties every entry to a verifiable identity and repository, creating a solid provenance trail. Other registries often rely on badges like “verified” or “official vendor,” but without transparent rules those can easily slip into marketing rather than meaningful assurance.

Publish​

Once identity is clear, developers need a straightforward way to get their servers listed. This can be a pull request against a spec repo, a web form, a CLI command, or a direct API call. Ideally, publishing also covers versioning, deprecation, and updates — not just the initial submission.

Discover​

Discovery is the user-facing side of the registry. It can be as barebones as a flat list or as rich as full detail pages with search, filters, tool breakdowns, client-connect guides, and ready-to-run install snippets. The more context provided, the faster users move from “I found it” to “I can use it.”

Governance​

Registries are not just catalogs, they are rulebooks. Governance defines what gets listed, what gets rejected, and how breaking changes are handled. Over time, these rules determine whether a registry matures into stable infrastructure or remains a fragile directory.

Programmatic access​

A modern registry must be more than a website. APIs, SDKs, and CLI tools should provide stable ways to read and publish entries. Nobody wants to scrape HTML to keep in sync. Standardized schemas and command-line workflows enable clients, gateways, and even other registries to federate data cleanly — turning a directory into a piece of usable infrastructure.

From Main Registry to Sub Registries​

The modelcontextprotocol.io team positions the official Registry as the primary source of truth and encourages public and private sub registries to build on top of it.

  • GitHub MCP Registry is today's clearest example of a true sub‑registry: publish once to the OSS community registry → entries appear automatically in GitHub, without duplicate submission.

  • By contrast, directories like Smithery, Raycast, MCP.so, PulseMCP, and FluidMCP currently require separate publishing. They act more like parallel registries than spec‑compliant subregistries. This distinction is crucial: the former supports a federated model, the latter risks fragmentation.

MCP Registries Compared​

While all MCP registries aim to solve the same core problem — making servers discoverable and usable — they diverge sharply in how they deliver that experience. First registries follow the specification from modelcontextprotocol.io closely and are designed for federation, ensuring consistency across clients and sub-registries. Most operate as standalone directories, requiring separate publishing and creating potential fragmentation. The following breakdown shows how today’s major registries position themselves along that spectrum.

modelcontextprotocol.io​

GitHub MCP Registry​

  • URL: https://github.com/mcp
  • Operator / Developer: GitHub, Inc.
  • true sub-registry: auto-syncs from modelcontextprotocol.io (no duplicate submission)
  • UI with curated listings and detail pages
  • install instructions for VS Code/VS Code Insider

Azure MCP Center​

Docker MCP Catalog / Toolkit​

Smithery​

  • URL: https://smithery.ai
  • Operator / Developer: Smithery.ai (US startup)
  • self-publishing via web, option to build and host MCP servers
  • rich detail pages incl. tool breakdowns, connect instructions (registration required)
  • CLI and API access + unclear “official vendor” badge criteria

MCP.so​

  • URL: https://mcp.so
  • Operator / Developer: Operator not clearly documented ⚠️
  • community-driven directory
  • searchable server pages, some link to Smithery or client guides
  • no standardized API for federation

PulseMCP​

  • URL: https://www.pulsemcp.com/servers
  • Operator / Developer: PulseMCP (personal project)
  • frequently updated directory with tags & editorial insights
  • submissions + curated entries
  • not federated, standalone directory

FluidMCP​

  • URL: https://www.fluidmcp.com/servers
  • Operator / Developer: Operator not clearly documented ⚠️
  • portal with upload + search/filter UX
  • shows “verified” badges (criteria unclear)
  • not federated, standalone directory

Further Reading​

Conclusion​

Registries are quickly becoming the control plane for MCP. The spec-first main registry at modelcontextprotocol.io is intended to be the single source of truth, with sub-registries like GitHub pulling directly from it. In contrast, most other registries require separate publishing or curation, which risks fragmentation. The critical challenge ahead is aligning these efforts with the federated model: publish once, mirror downstream, enrich with trust signals, and surface consistent metadata across clients. Only then will MCP move from fragmented directories to a truly interoperable infrastructure for agentic systems.