All posts
· 10 min read ·

Five MCP registries publish five different server counts. Discovery is now the load-bearing problem.

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.

Asking how many MCP servers exist in May 2026 returns five different answers depending on which registry you query. Glama indexes 21,000+; PulseMCP reports 11,840+ as of recent counts and curates them by hand; Smithery publishes 7,000+ with hosted remote-server runtimes; the official MCP Registry maintained under AAIF lists a smaller, community-vetted subset; GitHub's MCP Registry indexes a different subset filtered for GitHub-discoverable repositories; AWS launched its own Agent Registry in 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

MCP registries, by server count and curation style Six horizontal bars representing major MCP server registries in May 2026. Glama leads at 21,000-plus servers with auto-indexing plus hosted runtime. PulseMCP at 11,840-plus with hand-reviewed daily curation. Smithery at 7,000-plus with an app-store interface. The official MCP Registry, GitHub MCP Registry, and AWS Agent Registry each publish smaller, more curated subsets. The bars are sorted by published server count. MCP REGISTRIES · SERVER COUNT, MAY 2026 Glama auto + hosted gateway 21,000+ PulseMCP hand-reviewed daily 11,840+ Smithery app-store, hosted 7,000+ Official MCP Registry AAIF, community-vetted undisclosed subset GitHub MCP Registry repository-filtered repo-discoverable AWS Agent Registry AgentCore preview · Apr 2026 enterprise preview 0 10,000 21,000

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 — 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) 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 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 and about ERC-8004's three-registry design. 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; 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

← Back to blog Agenstry