A developer checks the Glama registry on a Tuesday afternoon, finds 22,775 MCP servers, picks one for Salesforce, wires it into their agent, and ships. Three weeks later a silent upstream API change starts returning malformed JSON. The server hasn't had a commit in five months. Nobody is fixing it.
That scene is not hypothetical. An audit of 1,847 publicly listed MCP servers across GitHub, npm, PyPI, and four community registries found that more than half are dead - no commits in 90+ days, broken builds, unpatched CVEs, or endpoints returning 5xx on every sample. The number most people cite when they talk about MCP's momentum is the one that matters least.
Why the server count became a vanity metric
The MCP ecosystem has evolved from 2025's "wild proliferation" into 2026's "infrastructure phase," with governance moved to the Linux Foundation and 22,000+ servers available on PulseMCP as of mid-July. That governance story is real and worth taking seriously. The server count is not.
Of 1,847 MCP servers audited: 52% are abandoned, 31% are lightly maintained, and only 17% meet a reasonable production bar. The median MCP server gets 6 commits in its lifetime and is last touched 142 days ago.
The failure mode isn't dramatic. An April 2026 analysis of 2,181 remote MCP server endpoints found that 52% were completely dead and only 9% were fully healthy. The remaining endpoints were degraded: responding slowly, returning stale data, or failing silently with 200 OK responses that contained parsing errors.
The MCP registry has the same quality problem as the npm registry circa 2016 - quantity does not imply reliability. That comparison is precise, and anyone who lived through the left-pad incident knows where it leads.
The steelman for the other side: a large registry does mean something. It means the protocol is attracting real developer attention, the spec is stable enough to build on, and the first-party servers from Stripe, GitHub, Linear, and Notion are genuinely production-grade. The more visible the vendor, the lower the dead rate. Stripe's MCP server is not going to disappear overnight. Some rando's "mcp-bitcoin-wallet-v0.0.1" almost certainly already has. The problem is that in a typical developer workflow, those two things appear next to each other in the registry with roughly equal weight.
That last sentence is the real problem. Presentation, not protocol.
The context tax most server lists don't mention
Even the servers that work carry a cost that doesn't appear in any registry listing. Every MCP server injects its full tool schema into the context window on every call. One team reported three MCP servers consuming 143,000 of 200,000 available tokens - 72% of the context window burned on describing what the agent could do, leaving barely enough room for what it should actually do.
The official GitHub MCP server charges roughly 42,000 tokens before any work begins. A more recent count put it at 55,000 across 93 tool definitions. That's roughly 21% of a 200K context window paid before your first prompt.
Scalekit's independent replication put it on real money: at 10,000 operations a month and Sonnet 4 pricing, the CLI path runs about $3.20 while the MCP path runs about $55.20. A 17x cost gap for identical operations is not a rounding error.
Scalekit found that an 800-token markdown file with gh tips actually outperformed 28,000 tokens of MCP schemas. The agent using the skills file made fewer tool calls and finished faster.
That result should make any team pause before installing their eighth server.
The fix isn't to abandon MCP. Dynamic toolsets - switching from static to on-demand tool loading - reduces input tokens by 91-97%. A hierarchical router that exposes just two meta-tools instead of ten-plus MCP servers saves 99.5% of context. These optimisations exist. They just require you to know the tax is there before it shows up on your invoice.
Beagle in action#engineering, 10:22amWhat actually separates production MCP from weekend demos
If you are wiring an agent to a real system, the choice of server matters more than the count of servers. Four checks separate the ones worth depending on from the thousands you should not: confirm it is first-party, documented on the vendor's own site or repository. A third-party wrapper can lag behind the product, break silently when the underlying API changes, or mishandle the credentials you hand it.
The database category is the clearest illustration of the quality variance. Database MCP servers are the most mature category. The best implement read-only modes, query timeouts, result size limits, and schema introspection. The worst allow arbitrary SQL execution without guardrails. Both appear in the same registry listing.
Security is where this gets serious. Low-quality, broken, and abandoned servers proliferate, with users reporting 30-50 percent installation failure rates on community servers. Security review is uneven; MCP servers run with substantial privileges and represent a meaningful attack surface that few enterprises audit systematically.
Growth has also brought more serious security challenges, including a systemic RCE disclosure from OX Security in April 2026 affecting all MCP SDK language implementations.
| Check | What to verify | Why it matters |
|---|---|---|
| First-party | Vendor docs or repo, not a community fork | Third-party wrappers break silently on API changes |
| Commit recency | Active commits in last 60 days | Median community server last touched 142 days ago |
| Tool allow-listing | Can you scope which tools load? | Schema preload is the primary cost driver |
| Auth model | OAuth 2.1 vs bare API key | API keys have no token expiry, no scope |
| Read-only mode | Enforced for data sources | Unrestricted DB access is a liability, not a feature |
Then there is the spec itself. On May 21, 2026, the MCP team locked the 2026-07-28 Release Candidate - the largest revision to the Model Context Protocol since its initial release. This is not a minor version bump. Six material changes arrive simultaneously.
Sessions are gone, two new HTTP headers are mandatory, error codes changed, and Roots/Sampling/Logging are deprecated. Any community server whose maintainer wasn't paying attention in May is now running a spec version the ecosystem is actively moving away from.
The teams getting value from MCP right now are running short, deliberate lists. Eight MCP servers run daily at one production agency: Filesystem, Puppeteer, Postgres, Brave, GitHub, Sentry, Notion, Linear. That is the stack that ships. The other 200 MCP servers in the ecosystem are largely demos or duplicates of these.
That observation generalises: GitHub MCP plus Context7 covers most backend developers; add Figma MCP and Playwright MCP for frontend work; add Brave Search or Perplexity for research. A tight list of first-party servers, with tool allow-listing enabled, beats a sprawling install of community wrappers every time.
Beagle in action#devops, 2:47pmMCP server quality: common questions
How many MCP servers are actually production-ready?
Of 1,847 servers audited, 52% are abandoned, 31% are lightly maintained, and only 17% meet a reasonable production bar. In practice this means a few dozen first-party vendor servers and a small set of well-maintained community servers carry nearly all real production traffic. The headline registry count tells you about developer interest, not deployability.
Why does MCP cost more tokens than CLI?
Every time you use MCP, the server injects the full schema for every single tool it supports into your context window. GitHub's tools include webhooks, gists, PR reviews, and dozens of things you probably don't need. But they all get loaded anyway. The fix is allow-listing the tools you actually use, or switching to CLI for single-operation calls where cross-tool composition is not needed.
What changed in the July 2026 MCP spec update?
The 2026-07-28 RC delivers on the roadmap in four areas: a stateless protocol core, the Extensions framework (MCP Apps and Tasks), authorization hardening, and a formal deprecation policy. Sessions are removed, two HTTP headers are now mandatory, and error codes changed. Community servers that haven't been updated since early 2026 are almost certainly non-compliant.
Should teams build their own MCP servers or use community ones?
For internal data - your database, your docs, your pricing logic - building first-party is usually the right call. A third-party wrapper can lag behind the product, break silently when the underlying API changes, or mishandle the credentials you hand it. A well-maintained server from a small agent-native tool beats an abandoned wrapper around a famous one. For standard external APIs (GitHub, Linear, Notion, Stripe), use the vendor's own server and nothing else.
How do you fix the MCP context tax without removing servers?
Four concrete fixes apply in descending order of ROI: enable Claude Code 2.0's tool-search subagent (measured 46.9% reduction), allow-list only the MCP tools you actually use, replace MCP calls with CLI for scoped operations (4-32x cheaper per operation), and move retrieval out of the agent loop into a context layer. Stacking the first two alone gets most teams to a 70-80% reduction without changing which servers they use.