30 CVEs in 60 days, a maintenance tax nobody warned you about, and what engineers are quietly switching to.
Your AI agent ran a query on a fake database last month.
It got real results. The tool worked perfectly. Your SSH keys left in the background.
The agent didn't flag it. The registry didn't catch it. Nobody warned you.
That's not a hypothetical. That's MCP in 2026, with 97 million monthly downloads and a Linux Foundation home.
The hype was real. So are the cracks.
First: what is MCP, and why should you care
If you've never built AI agents before, this matters. Skip it if you have.
Say you're building an AI assistant that needs to do real work:
- Look up customer records in a database
- Create tickets in Jira
- Send a Slack message
- Pull a file from Google Drive
Each of those lives in a different system. Different API, different auth, different data format.
To connect your AI to all of them, you'd write a custom integration for each one. Fine for two tools. Painful for ten. Then you switch models and rewrite everything.
This is the N×M problem: N tools multiplied by M AI models equals a mountain of glue code nobody wants to maintain.
MCP — the Model Context Protocol — solves that. Released by Anthropic in November 2024, it's an open standard that gives AI models one universal way to talk to external tools. You build an MCP server once around a tool, and any MCP-compatible AI can use it.
Your agent → MCP Client → MCP Server → Real Tool (Slack, Postgres, GitHub)
Three pieces:
- MCP Host: your app (Claude Desktop, VS Code, a custom agent)
- MCP Client: the component inside your app that speaks MCP, discovers tools, calls them
- MCP Server: a small process wrapping a real tool, exposing it in a format any MCP client can use
That's it. The N×M problem disappears. One integration per tool, works with every AI.
The pitch was real. The adoption proved it.
How MCP went from zero to everywhere in 14 months
The adoption happened fast. Unusually fast.
- Nov 2024 — Anthropic launches MCP. ~2M monthly SDK downloads.
- Apr 2025 — OpenAI adopts it. Downloads jump to 22M.
- Jul 2025 — Microsoft integrates it into Copilot Studio. 45M.
- Nov 2025 — AWS adds support. 68M.
- Mar 2026 — Every major AI vendor on board. 97M downloads. 10,000+ public MCP servers.
In December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, co-founded with OpenAI and Block. It stopped being Anthropic's protocol and became the industry's.
The "USB-C for AI" comparison spread everywhere. Everyone plugged in.
And then engineers started running it in production.
Why developers hate MCP
The complaints have been building in forums, GitHub issues, and private Slack channels for months. Not from people who misunderstood MCP. From people who ran it in production and got surprised by the same things.
"It's unauthenticated by default."
Out of the box, an MCP server trusts whatever connects to it.
No built-in check that the server is who it claims. No built-in check that the client is who it claims. You're responsible for adding that layer.
Most tutorials don't mention this.
"The STDIO transport executes arbitrary OS commands."
The official MCP STDIO transport runs any OS command you point at it to launch a server. Even when the server startup fails. No sanitization warnings. Nothing in the developer toolchain flags it.
OX Security documented this in April 2026.
Anthropic's response: expected behavior, sanitization is the developer's responsibility. LangChain said the same. Microsoft said the same.
Three major vendors. Same answer: your problem.
"The spec moves, community servers don't."
MCP servers published in community registries frequently fall behind spec updates. A server that worked last month may behave differently after the protocol updates. The registry has no enforcement mechanism. You find out in production.
"Every REST API I already have needs a new wrapper process."
Adding MCP to a tool that already has a clean REST API means building an entire MCP server around it.
That server needs to be:
- Deployed and monitored
- Updated when the underlying API changes
- Secured separately from both the agent and the tool
For ten existing APIs, that's ten new processes to own. Month three of production, you feel every one of them.
"The registries are basically npm circa 2015."
In early 2026, OX Security cloned mcp-server-postgres and named it mcp-server-postgress (extra 's'). Functionally identical. Same queries, same responses.
Hidden inside: a payload that silently pulled SSH keys and environment files to an outside server.
They submitted it to eleven major MCP registries.
Nine published it. No automated security review. No source code analysis. Nothing.
"It eats my context window before the user says anything."
When your MCP client connects to a server, it loads the full tool schema into your context window — names, descriptions, parameters for every tool.
- One server, five tools: ~500 tokens gone before the first message
- Ten servers: 2,000–3,000 tokens gone before the first message
The model is already reasoning over a smaller budget. Before your user typed a word.
These aren't edge cases. They're the standard experience for anyone who's moved past a local demo.
The 3 problems that actually break production systems
The trust problem
Your agent has no way to verify an MCP server is who it claims to be.
The OX Security incident made this real: nine out of eleven registries accepted a typosquatted credential-stealing package. The malicious server functioned correctly. Ran database queries. Returned results. And silently pulled your SSH keys in the background. Nothing in the protocol flagged it.
Since January 2026, researchers have filed 30 CVEs against the MCP ecosystem in 60 days. Prompt injection through tool descriptions. Credential theft via config file reads. "Tool poisoning," where a server description manipulates the agent's next decision. These aren't exotic attack vectors.
Your agent can't tell your Postgres server from an attacker's. That's not a code bug. It's a design gap.
MCP was built for a trusted local environment. Production isn't that.
The wrapper tax
Every tool you connect to MCP needs its own MCP server. Ten tools means ten additional processes to own.
Each one needs to:
- Stay in sync when the underlying tool's API changes
- Be monitored for failures in production
- Be secured separately from the agent and the tool itself
- Be deployed as part of your infrastructure
For the first two tools, manageable. Month three with fifteen integrations, it's a job.
The N×M problem is solved. The "N new processes" problem quietly replaced it.
The context window bill
Tool schemas are not free. They're tokens. And they arrive before your user's message does.
A team building a customer service agent connected to ten MCP servers found their available reasoning budget had shrunk by 30% before the first user question arrived. Same model. Same prompts. Just more tools.
In a long multi-step agent session, schema tokens compound. Quality drifts. Costs climb. Most teams don't trace this back to tool schema overhead until they look at what's actually in the context window.
What engineers are using instead
A few patterns have emerged for teams that ran into the problems above.
Direct REST API calls
For tools with a clean existing API, skip MCP entirely. Call the API directly from your agent. No new server to maintain, no schema overhead, existing auth covers it.
Works well when you control the tool and the API is stable. Doesn't scale when you need multiple AI systems to share the same integrations.
Native provider tool use
Anthropic and OpenAI both have built-in tool calling that needs no MCP infrastructure. You define the tool schema inline, pass it with the request, the model calls it.
- No server process
- No registry
- Your auth sits directly on the call
Most teams running focused single-purpose agents in 2026 are doing this. Simpler to reason about, harder to share across systems.
UTCP (Universal Tool Calling Protocol)
UTCP skips the wrapper entirely. Instead of wrapping a tool in an MCP server, it calls the tool's existing HTTP endpoints directly, with a discovery layer on top.
As of early 2026:
- 1,000+ GitHub stars
- Implementations in Python, Go, and TypeScript
- Growing community from teams that wanted lower latency and less infrastructure overhead
Best for teams with well-designed existing APIs who don't want a separate server layer. Not a full MCP replacement if you need the ecosystem breadth — but for many production use cases, materially simpler.
MCP with a gateway layer
For teams committed to MCP, the answer to most of the problems above is an MCP gateway — a controlled layer between your agent and your servers.
Your agent → MCP Gateway → MCP Server 1 → Tool
→ MCP Server 2 → Tool
→ MCP Server N → Tool
A gateway handles:
- Authentication — verifies server identity before your agent calls anything
- Tool filtering — loads only schemas relevant to the current task, not all of them
- Audit logging — records every tool call for compliance and debugging
- Rate limiting — stops runaway tool calls from blowing your budget
As of April 2026, 86–89% of AI agent pilots fail before reaching production. Governance gaps and audit visibility are the two most common reasons. A gateway is what closes both.
So do we actually need MCP?
Yes. With caveats that matter.
Use MCP when:
- Multiple AI systems need to share the same tools
- You're a SaaS company giving AI agents access to your product
- You need dynamic tool discovery across a large integration ecosystem
Skip MCP when:
- You're building a focused agent with two or three tools you already own
- Your tools have clean REST APIs you control
- You need low latency and minimal infrastructure overhead
The "MCP for everything" era is over. It's the right call when standardization pays off at scale. When you just need your agent to hit an API you already control, MCP is overhead pretending to be infrastructure.
Cheat sheet: what to actually do
| Your situation | What makes sense |
|---|---|
| Local dev, one or two tools, just exploring | Bare MCP or native tool calls. Don't over-engineer. |
| Agent using tools you own, clean REST APIs | Direct API calls or native tool use. Skip MCP overhead. |
| Production agent, 5+ tools, or external users | MCP with a gateway. Authentication is not optional. |
| Enterprise, compliance, or regulated industry | MCP gateway with audit logs and SSO. Non-negotiable. |
| Pulling from community MCP registries | Treat every server as untrusted. Verify before deploying. |
| Need to share tools across multiple AI systems | MCP is the right call. This is exactly what it's for. |
The actual state of things
MCP isn't going away. The downloads are real. The Linux Foundation governance is serious. Multi-vendor adoption means the protocol has institutional staying power.
But the MCP of early tutorials — install a community server, plug it in, done — that version is dead.
It was never safe for production. It was never meant to be.
The engineers moving to UTCP or direct API calls aren't abandoning MCP because it failed. They're routing around the parts that weren't built for what they're building.
I keep coming back to the OX Security test. Nine out of eleven registries. No automated review. The agent called the fake server, ran its queries, and handed over credentials it didn't know it was handing over.
Your agent does what it's told by the tools it trusts.
MCP hasn't fully answered how it decides what to trust. Until it does, treat every community MCP server the way you'd treat a random npm package in 2015.
You know how that era ended.
Top comments (0)