MCP registries, by server count and curation style

--- title: "Five MCP registries publish five different server counts. Discovery is now the load-bearing problem." date: 2026-05-18 summary: "Glama lists 21,000+ MCP servers, PulseMCP 11,840+, Smithery 7,000+, and the official AAIF registry a smaller curated subset. The numbers don't agree, the curation policies don't agree, and the discovery decision is now upstream of every consumer in the stack." slug: mcp-discovery-fragmentation author: "Sebastiaan Hilbers" hero_glyph: grid --- Asking how many MCP servers exist in May 2026 returns five different answers depending on which registry you query. [Glama indexes 21,000+](https://glama.ai/mcp/servers); [PulseMCP](https://www.pulsemcp.com) reports 11,840+ as of recent counts and curates them by hand; [Smithery publishes 7,000+](https://smithery.ai) with hosted remote-server runtimes; the [official MCP Registry](https://registry.modelcontextprotocol.io) maintained under AAIF lists a smaller, community-vetted subset; [GitHub's MCP Registry](https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/) indexes a different subset filtered for GitHub-discoverable repositories; [AWS launched its own Agent Registry in preview](https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview/) on April 30. The numbers don't agree, the curation policies don't agree, and the same server can appear in three of them under three different metadata profiles. This isn't a counting problem. It's a discovery problem, and discovery at the population scale the MCP ecosystem has reached is structurally different from discovery at 100 servers. ## The fragmentation, in numbers The headline number is roughly 3:1 between the largest aggregator and the largest curated index. That ratio is the population-vs-curation problem: Glama auto-indexes everything that looks like an MCP server and hosts a runtime for connecting to it; PulseMCP is hand-reviewed since MCP's launch week; the official Registry only lists what passes its publication criteria. None of these are wrong. They are different objects with different load-bearing claims. ## Why discovery breaks at 10,000+ At a hundred MCP servers, discovery is a list. A developer reading the list once a quarter has read most of it. At ten thousand, discovery becomes a search problem with all of search's adjacent failure modes: ranking has to be tuned; semantic equivalents have to be deduplicated; malicious typosquats become economically attractive; the cost of publishing a new server drops below the cost of evaluating one. The MCP project's response has been to invest in [semantic search over the registry](https://github.com/lastmile-ai/mcp-registry-search) — a hybrid lexical + pgvector index over server descriptions and input schemas. That work matters and will keep mattering. It is also downstream of a more basic question: which underlying registry should the index point at, and what does a consumer learn by selecting one over another? The Agenstry-relevant observation is that the answer changes per consumer: - A coding-agent vendor (Cursor, Devin, Copilot) embeds an MCP registry into its install path. That vendor's choice (which registry to surface in the install UX, how to filter its results) is a discovery decision the user will not see and cannot override. - An enterprise platform team running an internal MCP gateway (see [Uber's pattern](https://agenstry.com/blog/uber-1500-agents-gateway)) curates a private subset of the public population. Public registry choice determines the seed set; internal scanning determines what makes the cut. - A consumer agent talking to a third-party MCP server has to trust *some* registry's claim that the server exists and is what it says. The signature on an [A2A Signed Agent Card](https://agenstry.com/blog/a2a-signed-cards-key-not-identity) proves the card was signed by a key. The registry's role is to bind the key to a published identity. Different registries make that binding to different degrees. Three different consumers, three different discovery problems, and the same underlying server population. The question every layer of the stack faces is which registry's discovery output it should treat as canonical. ## What separates a registry from an aggregator A useful way to read the six entries above is by whether they are populating their list or curating it. Glama and PulseMCP are aggregators with curation overlays — Glama auto-indexes and adds a hosted gateway; PulseMCP indexes and edits the result. Smithery is closer to an app store: it accepts submissions and standardizes the install UX. The Official MCP Registry, GitHub MCP Registry, and AWS Agent Registry are governance-driven: they list what passes a stated publication policy, which means fewer servers and more uniform metadata. The difference matters for a downstream consumer because it changes what "this server is in registry X" actually proves. In Glama, it proves the server's repository is parseable and was found by the crawler. In PulseMCP, it proves the founder reviewed it. In the Official Registry, it proves the server passed AAIF's intake. None of those is the same claim. None of them, on its own, is the same claim as "this server, when probed today, served a valid card and responded to a known tool call." The split between published claim and probed evidence is the same distinction [this blog has been making about MCP server conformance](https://agenstry.com/blog/mcp-spec-vs-probe-evidence) and about [ERC-8004's three-registry design](https://agenstry.com/blog/erc-8004-three-registries-honesty). The discovery story is one layer further out: even the question "which servers exist" has multiple defensible answers, and a consumer needs to know which answer they are reading off of which registry. ## What we're watching Three things, observable within the next two quarters: 1. **Whether the official AAIF registry adopts a federation interface.** The current architecture is a single hosted index. A federation schema that lets Glama, PulseMCP, Smithery, and others publish into and query out of the same envelope would do for MCP discovery what BGP did for routing tables: not pick a winner, but make the shape of the disagreement legible. 2. **Whether typosquatting and supply-chain attacks land in the MCP ecosystem at the scale they did in npm.** The economics now favor them: 10,000+ servers, low publication cost, multiple unfederated indexes. The first widely reported incident will reshape the discovery conversation overnight. 3. **Whether a probe-driven registry layer becomes a standard part of the discovery stack.** A registry that publishes "this server responded to a known card request today" gives a downstream consumer a signal that *no current registry* publishes uniformly. That signal is what [Agenstry publishes](https://agenstry.com); the open question is whether probe data becomes a layer the public registries syndicate from each other or whether it stays a separate consumer-side responsibility. The 100-server problem was a list. The 10,000-server problem is an index. The 10x problem coming next is federation and verification of those indexes against each other. Discovery is the load-bearing question right now, and the count of MCP servers is the part of the answer that's easiest to publish without giving the consumer anything they can act on. ## Sources - [Glama MCP server catalog](https://glama.ai/mcp/servers) — Glama, accessed May 2026. - [PulseMCP](https://www.pulsemcp.com) — PulseMCP, accessed May 2026. - [Smithery](https://smithery.ai) — Smithery, accessed May 2026. - [Official MCP Registry](https://registry.modelcontextprotocol.io) — Agentic AI Foundation, accessed May 2026. - [Meet the GitHub MCP Registry: The fastest way to discover MCP Servers](https://github.blog/ai-and-ml/github-copilot/meet-the-github-mcp-registry-the-fastest-way-to-discover-mcp-servers/) — The GitHub Blog, 2026. - [AWS Agent Registry for centralized agent discovery and governance is now available in Preview](https://aws.amazon.com/about-aws/whats-new/2026/04/aws-agent-registry-in-agentcore-preview/) — AWS, April 30, 2026. - [lastmile-ai/mcp-registry-search](https://github.com/lastmile-ai/mcp-registry-search) — semantic search ETL pipeline for the MCP server registry, accessed May 2026.