You’ve seen the headlines. 15,000+ MCP servers! The ecosystem is exploding. Every week, another startup announces they’re building on the Model Context Protocol. It feels like a land rush, a gold rush, a network effect that’s unstoppable.
But I spent last week running a health check on every single one of those servers. And the reality? It’s not pretty. Most of those servers are dead weight. They’re unmaintained, unreliable, or just plain broken. The number of MCP servers is a vanity metric that hides a rotting infrastructure.
If you’re building on MCP, you need to know which servers you can actually trust. Because the difference between a thriving ecosystem and a bubble is whether the infrastructure can deliver on its promise.
Let me walk you through what the census found — and why it changes everything.
First, the raw numbers are impressive. The MCP Census cataloged 15,382 unique servers. That’s a lot of people building things. But when you start testing them — checking if they’re actually online, responding, and returning useful data — the picture shifts. Over 60% of MCP servers failed basic connectivity checks. Many hadn’t been updated in months. Some were abandoned repositories that had never been deployed.
I saw servers that returned the same static response for every query. I saw servers that crashed on the second request. I saw servers that were clearly just experiments — one-off demos that were never meant to be production-grade.
And here’s the kicker: the ecosystem is celebrating this quantity as a sign of health. But if you’re an engineer trying to integrate MCP into your product, you’re not looking for a million toy servers. You’re looking for a handful that you can rely on. Quantity without quality is just noise — and noise kills trust.
This isn’t to say MCP is doomed. It’s to say we’re at a dangerous inflection point. The hype cycle is real. Investors are pouring money into startups that claim to be MCP-native. But the underlying infrastructure is still a ghost town with a coat of paint.
I’ve seen this pattern before. The early web had thousands of broken links. The early app store had millions of zombie apps. The difference is that those ecosystems had a few anchor platforms that actually worked. For MCP, we’re still waiting for those anchors. The protocol’s future depends not on the number of servers, but on the willingness to kill the dead ones.
So what should you do? If you’re building on MCP, start by running your own health checks. Don’t trust the directory listings. Test every server you plan to use. And if you’re a server maintainer, be honest about your maintenance status. A server that’s not maintained is a liability — for you and for everyone who depends on it.
The MCP ecosystem has potential. But it’s potential that’s currently buried under a mountain of abandoned code. The next step is to separate the signal from the noise. Because in an ecosystem of 15,000 servers, the one that actually works is worth more than all the rest combined.
FAQ
Q: How many MCP servers are actually reliable?
A: Based on the health check, less than 40% passed basic connectivity and functionality tests. Many are abandoned or never intended for production use.
Q: Should I stop using MCP because of this?
A: No. The protocol itself is promising. But you need to be selective. Don't rely on raw server counts. Independently verify every server you integrate.
Q: Isn't a high number of servers a good sign for the ecosystem?
A: Only if they work. Quantity without quality creates a false sense of momentum. The real health metric is the number of servers that are actively maintained and reliable.