Most MCP Servers Die Before Production. Yours Does Not Have To. | CloudWeld

MCP & Agents

Most MCP Servers Die Before Production. Yours Does Not Have To.

Claudia StanJune 22, 202611 min read

MCP won the protocol war, and it was not close. It is governed by the Linux Foundation now, backed by Anthropic, OpenAI, Google, Microsoft, and AWS, and it is the standard way a product ends up usable inside Claude, ChatGPT, and Cursor. If you run a SaaS product, the question of shipping an MCP server is no longer if. It is when, and who builds it.

Here is the part the announcements leave out: most MCP servers that get built quietly fail. An audit of 1,847 public servers found 52 percent effectively dead, 31 percent barely maintained, and only 17 percent production-ready (RapidClaw’s analysis). That is not a story about a bad protocol. It is a story about what it actually takes to ship one, and how consistently teams underestimate it.

Why generating one is trivial, and finishing one is not

The reason so many servers exist, and so few survive, is that the first ten percent got easy. FastMCP, Speakeasy, Stainless, and Postman will all turn an OpenAPI spec into a working MCP server in minutes. That is genuinely useful, and we use those generators ourselves as a starting point.

What they produce is a demo. The generator vendors say so in their own documentation: authentication wiring, rate limiting, and tool curation are explicitly out of scope. So you get a server that works on your laptop, talks to Claude, and then meets the three things that actually kill MCP servers in production.

Killer one: authentication and tenancy

An MCP server wired to your product’s data, without real authentication and per-tenant isolation, is an open API wearing a costume. This is not a rare oversight. Independent scans put the share of public MCP servers with no authentication at all between 38 and 41 percent, and Microsoft measured OAuth adoption below 9 percent (their writeup).

It is also the first thing a real customer’s security team asks about, and where deals stall. The OWASP MCP Top 10 now catalogs the specific attack classes, including tool poisoning, where malicious instructions are hidden inside tool metadata that the model reads as trusted. Getting this right means real OAuth with least-privilege scopes, tenant isolation you have tested by trying to cross it, and audit logs that can reconstruct what an agent did. None of that is generated for you.

Killer two: tool design is editorial, not automatic

Generators map every API endpoint to a tool. It sounds thorough. It is actively harmful. A large API becomes hundreds of tools, and a wall of tool definitions overwhelms the model before the conversation even starts. Tool definitions have been measured eating most of a 200,000-token context window on their own, and Perplexity’s CTO publicly stepped back from MCP internally over exactly this cost. That is a warning about doing it naively, not a verdict on the protocol.

Good tool design is curation, and it is a real discipline. Fewer, task-shaped tools that map to what an agent actually needs to do, not to your internal REST routes.

The difference is not cosmetic. It is the difference between an agent that reliably does the right thing and one that burns tokens flailing through a menu. And it can only be done by a human who understands both your product and how models actually behave, tested against the real clients that will call it.

Killer three: the spec keeps moving

This is the one that catches even good teams. MCP is young and evolving fast, and “evolving” means breaking changes on a schedule.

In the RapidClaw audit, a large share of the dead servers could no longer even connect to current clients, because they were built against a spec version that modern clients no longer speak. A server you ship and forget has a shelf life measured in months. This is not a reason to avoid MCP. It is a reason to budget for the upkeep, or to work with someone who tracks the spec so a protocol release does not silently take your integration offline.

What production-grade actually means

When we say an MCP integration is production-grade, we mean it can answer yes to every one of these. It is a useful checklist whether you build it yourself or not.

1. Real OAuth with least-privilege scopes, not a static API key sitting in an environment variable.
2. Per-tenant isolation that has been tested by actively trying to cross it, not just assumed.
3. Rate limits at the MCP layer, so an agent’s retry loop cannot hammer your API into the ground.
4. A curated tool surface, designed and tested against the real models that will call it.
5. Audit logging that can reconstruct what an agent did, and why, after the fact.
6. Confirmation gates on destructive actions, so a poisoned instruction cannot quietly delete things.
7. A version strategy with a named owner for spec migrations, so the next breaking change is a planned afternoon, not an outage.

None of this is exotic engineering. It is the same discipline as any serious public API, applied to a surface where the caller is a language model and the failure modes are newer. The gap between the 17 percent that make it and everyone else is mostly that someone decided to do this part of the work instead of stopping at the demo.

Generated is a starting point, not the product

We are not purists about this. On most builds we start from a generated server too, because there is no reason to hand-write boilerplate a tool produces in seconds. The value, and the entire reason a server ends up in the 17 percent instead of the 52, is everything that comes after: the auth, the tenancy, the curation, the guardrails, and the plan for the next spec release.

That is the honest shape of the work. The first version takes an afternoon. The version that survives contact with a customer’s security team, and keeps working next quarter, takes real engineering. Skipping the second part is exactly how the graveyard got so full.

Agent-Ready Integrations

Shipping your product into Claude or ChatGPT?

We design, build, and harden MCP servers that pass enterprise review, and we keep them alive through the spec changes. Scoped and fixed-priced after a call.

Book a Scoping CallHow We Build Integrations

Continue Reading

Related Articles

[

ai-codebases-investor-diligence

Production

Your Codebase Is 95 Percent AI-Generated. Investors Now Check.

CloudWeld

AI-generated codebases stopped being a curiosity and became a due-diligence line item. What technical reviewers actually look for, what it does to your valuation, and how to be ready before the data room opens.

10 min read

](/blog/ai-codebases-investor-diligence)[

what-actually-breaks-in-ai-built-apps

Security

What Actually Breaks in AI-Built Apps: The Incident Record

CloudWeld

Missing access rules, leaked keys, and deleted databases. A tour of the documented failures in AI-built software, why it is always the same five things, and the short list of fixes that would have prevented most of them.

11 min read

](/blog/what-actually-breaks-in-ai-built-apps)[

the-flat-rate-ai-era-is-over

AI Costs

The Flat-Rate AI Era Is Over. Here Is the Math That Replaces It.

CloudWeld

In June 2026, AI coding tools and subscriptions switched from flat rates to meters, and a lot of budgets broke in the same month. What happened, why it was inevitable, and how to engineer your way back to predictable costs.

9 min read

](/blog/the-flat-rate-ai-era-is-over)