Ask how big the Model Context Protocol ecosystem is and you will get a confident answer. Ask twice and you will get a different confident answer. As of late May 2026, the official MCP Registry is variously described as holding around 2,000 servers, or 9,652 "latest server records," or 28,959 records once you count every version of every server separately. Step outside the official registry and the floor drops out: PulseMCP lists more than 15,930; Smithery, roughly 7,300; one aggregator sweeping the official registry, Glama, Smithery, mcp.so, and the GitHub MCP organization reported 59,312 servers on June 3, 2026 — while noting, in the same breath, "potential duplicates."
So: 2,000 to 59,000, a thirtyfold spread, for a single question asked in a single fortnight. Before you treat any of these as the headline, sit with the spread itself. It is the most informative statistic in the entire dataset, and almost nobody reports it.
What a "server count" actually counts
The numbers disagree because they are not measuring the same object. A count of records in a registry counts submissions — including every version bump, every fork, every abandoned weekend project that was published once and never pinged again. A count across aggregated registries double-counts: the same GitHub repo appears in the official registry, on Smithery, and on mcp.so, and a naive union adds it three times. PulseMCP's 16,000 and the official registry's 2,000 are not in tension; they are answers to different questions — how many have ever been listed somewhere versus how many cleared the official submission bar.
"Number of MCP servers" is not a measurement. It's a category error wearing a measurement's clothes.
This is the oldest failure mode in adoption metrics, and the AI ecosystem keeps walking into it because the big number is good for everyone who quotes it. The same reports that headline server counts also cite 97 million monthly SDK downloads and 81,000 GitHub stars (as of March 2026). Both are real and both are nearly useless as adoption signals. SDK downloads are dominated by CI pipelines re-pulling the package on every build; a single project with a busy continuous-integration setup can generate thousands of "downloads" a month without a human ever invoking a server. Stars measure attention, not use. None of these count the only thing a buyer cares about: how many MCP servers are maintained, reachable, and actually called in production.
The number that is trying to tell you something
If you want a metric with teeth, stop counting servers and start counting failures. A first-year security review of the protocol catalogued roughly 30 CVEs and scanned about 500 servers — and the finding was not "a handful of bad apples" but a fast-growing attack surface full of misconfiguration, because most of those tens of thousands of "servers" are unmaintained code exposing tools to a model with little auth and less review. That is what the 30x spread is hiding. The gap between 2,000 and 59,000 is precisely the population of servers nobody is maintaining, nobody is securing, and — when you actually try to connect — a large fraction nobody is even hosting anymore.
The honest dashboard for MCP in mid-2026 has three rows, and "total servers" is not one of them:
- Reachable: of the listed servers, how many answer a request today. (No public tracker reports this; the registries don't health-check.)
- Maintained: how many have a commit in the last 90 days. This is knowable from the GitHub data the trackers already ingest, and it would collapse the headline number by an order of magnitude.
- Secured: how many pass a basic auth-and-permission scan. The CVE work suggests the answer is "alarmingly few."
The maturity signal that isn't a headcount
Here is the irony. While the ecosystem brags about server counts, the protocol itself just produced the only number that actually signals maturity, and it is not a count at all. The 2026 specification release candidate rebuilds MCP to be stateless: it removes the session handshake and the Mcp-Session-Id header so that requests are self-contained and can route through ordinary load balancers. That is not a growth metric. It is a plumbing decision, the kind you only make when real traffic at real scale forces it — the protocol equivalent of a startup quietly rewriting the part that kept falling over.
That tells you more about MCP's trajectory than 59,312 ever could. A protocol earns the right to obsess over load balancing by having load to balance. Watch that work, and watch the reachable-and-maintained fraction if anyone ever bothers to publish it. Ignore the server count. It's the one number in this entire ecosystem that grows fastest precisely when it means least.
