9,652 Servers and Counting: What's Actually in the MCP Registry

Walk into the MCP Registry today and you're not looking at one ecosystem — you're looking at two, layered on top of each other and easy to mistake for a single mass. As of May 24, 2026, the registry counted 9,652 latest server records. That's the number that gets quoted. What's more interesting is what's inside it, because the composition tells a very different story than the headline count.

The long tail is exactly what you'd expect

Most of those 9,652 servers are what you'd predict from any young, fast-growing developer ecosystem: individual developers and small teams wrapping an API, a database, a local tool, or a niche service in an MCP interface because it was useful for their own workflow and cheap to publish once built. Some of these are excellent and actively maintained. A lot of them are one-person side projects, published once and left alone — the same distribution you'd find in any npm or PyPI namespace at comparable scale. That's not a criticism; it's just what an open registry with a low publishing bar looks like at nearly ten thousand entries. Quantity and quality are only loosely correlated in that layer, and treating "it's in the registry" as a quality signal on its own is a mistake worth naming early in this piece, because the rest of the piece explains why.

The layer that actually signals something new

The more telling number sits inside the total: more than 950 of those registry entries are business application servers — tooling built for customer service, sales automation, and internal operations. That's a meaningfully different category of server than a wrapper around a public API someone built over a weekend. Business application servers get built when a company decides MCP is the right interface for connecting AI systems to functions that touch real customers, real deals, and real internal processes. That's a commitment with maintenance obligations, security review, and often a product roadmap behind it — a different kind of bet than publishing a personal utility.

The 950-plus business-application servers are the second wave of MCP adoption, and they matter more to the protocol's future than the other roughly 8,700 combined, because they're the servers being built by organizations that have already decided MCP is infrastructure worth investing in, not just infrastructure worth trying.

Why "enterprise second wave" is the right frame

Most developer protocols go through a recognizable arc. Wave one is enthusiast and hobbyist adoption — people building things because the protocol is new and interesting, often disconnected from any production business need. Wave two, if the protocol survives long enough to get there, is enterprise and business adoption — organizations building on the protocol because it now solves a real operational problem better than the alternatives, and because enough of the ecosystem exists that the integration risk feels manageable.

A lot of protocols never make it to wave two. They get a burst of hobbyist registry entries, plateau, and fade as the novelty wears off, without ever crossing into serious business tooling. The presence of a 950-plus-server business-application segment inside the MCP Registry, growing alongside — not instead of — the long tail, is the clearest evidence in this whole series that MCP crossed that threshold. Customer service and sales automation servers don't get built and maintained by companies chasing developer-conference novelty. They get built because a support team or a sales ops function found MCP to be the right connective layer for wiring AI into a workflow that has to work every day.

What the registry doesn't tell you

Registry presence is not the same as registry quality, and this is where the ecosystem's growing pains show. A 2026 security audit of more than 2,600 MCP servers found 82% vulnerable to path traversal and 67% vulnerable to code injection — findings covered in depth elsewhere in this series, but relevant here because they apply disproportionately to the long tail, not the enterprise layer. A server built by a company shipping a customer service product typically goes through security review before it ships. A server built by an individual developer over a weekend, published to a low-friction public registry, often does not. Nearly 10,000 entries in a registry is not nearly 10,000 entries you should trust equally, and the registry's own structure — a single flat listing without a strong maturity or trust tier — doesn't help a builder tell the two layers apart at a glance.

How to actually use the registry if you're picking servers

Treat the total count as a measure of ecosystem breadth, not a measure of any individual server's trustworthiness. When you're evaluating a specific server for a real integration, the questions that matter are closer to: is this maintained by an identifiable team or company, does it have a security review history, is it one of the 950-plus servers built for a genuine business application, or is it a long-tail utility that happens to work well enough for its original author's use case. Those questions get more useful answers than "is it in the registry," because at this point, almost everything is in the registry.

A useful mental model: think of it as two registries in one

The clearest way to hold this is to stop thinking of "the MCP Registry" as a single thing and start thinking of it as two overlapping registries that happen to share one search box. Registry one is a long-tail directory of developer utilities — closer in spirit to a personal-project showcase than a curated marketplace, useful for discovery but not for trust. Registry two is a much smaller, much higher-stakes directory of production business tooling, where the 950-plus business-application entries live, and where the bar for actually shipping something is set by each publishing organization's own product and security standards rather than by the registry's near-nonexistent gate.

Treating those as one undifferentiated pool of "9,652 MCP servers" is where a lot of the loose thinking in this ecosystem comes from — both the overly rosy "look how big MCP already is" framing and the overly alarmed "82% of everything in here is vulnerable" framing. Neither framing is wrong about its own layer. Both are wrong the moment they get applied to the registry as an undifferentiated whole, because the two layers behave completely differently on every axis that matters: who built it, why, under what review process, and with what to lose if it breaks.

What the registry's shape says about where MCP goes next

A protocol's registry composition, tracked over time, is a leading indicator of where the protocol is heading. If the business-application share keeps growing faster than the long tail, that's a sign MCP is becoming genuine enterprise infrastructure rather than staying a developer curiosity with an enterprise footnote. If the long tail keeps growing while the business-application share stalls, that's a sign the protocol topped out at wave-one adoption. Right now, with 950-plus business-application servers already inside a 9,652-server registry just seven months after the Linux Foundation handoff, the shape of the curve favors the first outcome — but it's a number worth watching, not a verdict to bank on yet.

Part of the "MCP One Year In" series on aiskill.market.