Last week I wrote about building AI agents without frameworks. Some of you reached out with some version of the same question: "But what about MCP? Isn't that the one standard we're all supposed to rally behind?"
Then, four days ago, Perplexity's CTO Denis Yarats walked onto the stage at their Ask 2026 conference and said what a lot of us had been thinking: they're moving away from MCP internally. In favor of what? Plain APIs and CLIs. The tools we've had for 30 years.
Garry Tan, Y Combinator's president, followed up the same day: "MCP sucks honestly." Pieter Levels called it dead. Twitter/X turned into a warzone.
But here's the thing, Yarats didn't say anything new. He said what production engineers have been discovering for months: MCP's elegant "USB-C for AI" metaphor crashes hard into reality when you actually try to ship with it.
I've been running MCP servers in production for some time, This is my honest assessment.
First, What MCP Actually Is (30-Second Version)
Model Context Protocol is an open standard by Anthropic that lets AI models connect to external tools and data sources through a standardized interface. Think of it like a universal adapter, instead of every AI tool needing a custom integration for every service, MCP provides one protocol to rule them all.
The pitch: build an MCP server once, and it works with Claude, ChatGPT, Cursor, VS Code, and any other MCP client.
The reality is... more complicated.
The Context Window Tax Nobody Warned You About
This is the criticism that hit me hardest in production, and it's the one Yarats led with.
Every MCP tool you connect sends its entire schema, every parameter definition, every description, every response format, into the LLM's context window. On every single turn.
Let me make that concrete. A GitHub MCP server with its full tool set? ~50,000 tokens just to initialize. A database MCP server with 106 tools? 54,600 tokens consumed before you ask a single question. Connect five servers with fifty tools between them and you've dumped 30,000–60,000 tokens of definitions, a phone book on the desk, before the model even starts thinking about your problem.
Cloudflare published a technical breakdown showing traditional MCP tool-calling can waste up to 81% of the context window for complex agents. MCPGauge research found it can inflate input-token budgets by up to 236x.
And you're paying for every one of those tokens. At scale, the MCP tax is a real line item.
The absurd part? The owner parameter appears in 60% of GitHub's MCP tools. repo appears in 65%. Same definition, copied dozens of times, eating tokens for the exact same boilerplate. There's no deduplication. No lazy loading. No "only send what's relevant." Every tool, every turn, every token.
Compare that to a direct API call where you pass exactly the parameters you need, when you need them, and the model never sees a schema it isn't using.
Security: The Part That Should Scare You
I'm a DevOps engineer. Security is my job. And MCP's security track record makes me want to rm -rf every server config I've ever written.
43% of tested MCP implementations had command injection flaws. That's not my number, that's from Equixly's security research. 30% were vulnerable to server-side request forgery. 22% allowed arbitrary file access.
Here's a sampler of what's been found:
The mcp-remote npm package (558,000+ downloads) had a CVSS 9.6 vulnerability, shell command injection via crafted OAuth metadata. Over 437,000 developer environments potentially compromised.
Invariant Labs demonstrated a malicious MCP server silently exfiltrating a user's entire WhatsApp message history. Silently. No warning.
Security researcher Shrivu Shankar showed MCP tool descriptions can inject backdoors into code generated by Cursor. Because tool descriptions are treated as system-level context, they carry elevated authority.
Anthropic's own MCP Inspector tool had an RCE vulnerability — unauthenticated remote code execution.
Knostic scanned nearly 2,000 internet-exposed MCP servers and found zero authentication across all of them. Not weak auth. No auth.
Red Hat documented a sandbox escape in the Filesystem MCP server — a naive prefix string check that allowed arbitrary code execution.
The architectural issue runs deeper. The MCP spec originally treated servers as both resource servers and authorization servers, a conflation that makes Dick Hardt, co-author of the OAuth 2.1 spec, wince. The spec requires anonymous Dynamic Client Registration, meaning any client can register as valid without identifying itself. Christian Posta, Global Field CTO at Solo.io, published the definitive critique: MCP's authorization model is "a non-starter for enterprise."
When RSA Conference 2026 reviewed MCP-related security submissions, fewer than 4% were about opportunity. The security community sees MCP overwhelmingly as a risk vector.
The "Just Use HTTP" Argument Is... Annoyingly Correct
This is where it gets embarrassing for MCP advocates.
Simba Khadder from Featureform made the strongest technical case: MCP reinvents HTTP semantics on top of JSON-RPC. Reading a resource requires sending a POST request with a URI buried in a JSON body, then receiving the response on a separate SSE connection.
A standard HTTP GET would do the same thing. In one request. With 30 years of tooling, caching, CDN support, and developer knowledge behind it.
The stdio-first design was particularly baffling, Claude Desktop didn't even support HTTP clients initially, requiring developers to build a proxy to use what should have been the default transport.
The UTCP project team captured the absurdity perfectly: wanting your LLM to read a file requires building a stateful server and doing multiple transactions. For something cat handles in microseconds.
Eric Holmes, an infrastructure engineer, published "MCP Is Dead, Long Live the CLI" and catalogued the daily pain: flaky initialization, endless re-authentication loops, all-or-nothing permissions. His conclusion? MCP provides no real-world benefit over well-structured CLI tools.
And honestly? When I look at my own agent setup, the tools that work most reliably are the ones that shell out to curl and jq. Not because that's elegant. Because it's understood.
Production Horror Stories from the Trenches
The gap between "watch this MCP demo" and "run this in production for 3 months" is a canyon.
The 16-hour hang: A developer reported an unresponsive MCP server caused a complete system hang in Claude Code, no timeout, no stuck detection. They had to manually terminate 70+ zombie processes.
The stale session nightmare: Another documented that stale session IDs after MCP server restarts forced 14 full Claude Code restarts over 7 days 53 mentions of stale-session issues in transcripts, with full context reloads each time.
The cascade failures: Microsoft's Playwright MCP server crashes deterministically on any page with console output. Every published version of AWS's OpenAPI MCP server failed to start due to missing dependency constraints. Firebase's MCP server crashes with OOM errors on any project with production-scale Crashlytics data.
These aren't edge cases. These are major companies' official MCP implementations failing on basic scenarios.
Nx deleted most of their MCP tools in February 2026, replacing them with "Skills", structured instructions loaded on-demand. Their benchmarks showed skills outperformed MCP on both accuracy and code generation. That's not a company giving up on the concept. That's a company measuring the results and making the right call.
One developer captured the sentiment that resonated across every MCP discussion I've seen: "I watched a team spend a week building an MCP integration for something curl | jq would've handled in eleven seconds."
The Bull Case (Because I'm Trying to Be Fair)
MCP's defenders aren't wrong about everything. The institutional support is real:
- Sam Altman committed OpenAI to MCP support across products
- Demis Hassabis at Google endorsed it
- Microsoft embedded MCP in Windows 11 and Copilot Studio
- The Linux Foundation accepted MCP, co-founded by Anthropic, Block, and OpenAI
The ecosystem numbers are substantial: 5,800+ verified servers, 17,000+ across all registries, ~50,000 GitHub repos, 300+ clients. Gartner predicts 75% of API gateway vendors will have MCP features by end of 2026.
And the core arguments have merit:
Dynamic tool discovery, agents finding and using tools at runtime without hardcoding is genuinely something direct APIs can't do. If you're building an open-ended agent system where the toolset isn't known at development time, MCP offers something real.
The N×M problem: MCP theoretically reduces M×N integrations to M+N. For a massive ecosystem, that math matters.
One HN commenter put it well: "Comparing MCP to local scripts is like calling USB a fad because parallel ports worked for printers."
Where I Actually Land
After 9+ months of running MCP in production, here's my honest take:
MCP solves a real problem: standardized tool connectivity for AI - but solves it at the wrong layer.
The protocol was designed for a world where Claude Desktop was the primary client and stdio was the primary transport. That world lasted about four months. Now we have browser agents, CLI-native coding tools, multi-agent systems, and production pipelines that need the reliability guarantees of real infrastructure — not a shiny new protocol still figuring out its auth story.
Here's my decision framework for new projects:
Use MCP when:
- You're building a tool for the MCP ecosystem (Cursor, Claude Desktop, etc.)
- Dynamic tool discovery is genuinely necessary
- The integration is low-stakes and dev-facing
- You're prototyping and need quick plug-and-play
Skip MCP and use direct APIs/CLIs when:
- You're building production agents with known, stable toolsets
- You care about context window efficiency
- You need enterprise-grade auth
- Token cost matters at your scale
- Reliability is non-negotiable
The Perplexity CTO was right, but not because MCP is fundamentally bad. He was right because for most production use cases in March 2026, the alternatives are more mature, more secure, more efficient, and more debuggable.
What Would Actually Fix MCP
The March 2026 roadmap from David Soria Parra (MCP's lead maintainer) shows the team knows what's broken. They've explicitly acknowledged gaps in horizontal scaling, stateless operation, and middleware patterns. But knowing and fixing are different things.
Here's what I'd need to see before moving back:
Lazy tool loading. Send schemas on-demand, not the entire registry on every turn. This alone would solve half the complaints.
Real auth. Not "every server rolls its own OAuth." A proper delegation model with enterprise SSO support.
Stateless operation. Crash recovery shouldn't require a full restart. Sessions shouldn't go stale after a server redeploy.
A security audit. An actual, funded, third-party security review of the core protocol and reference implementations. The 43% command injection rate is not a growing pain, it's a fire.
Tool routing. Don't dump 106 database tools into context when the user asked about a weather forecast. Client-side tool selection should be table stakes, not an afterthought.
Cloudflare's "Code Mode", where the LLM writes TypeScript to call tools instead of calling MCP directly might be the most telling signal of where things are heading. When major cloud providers start building around your protocol rather than through it, that's a message.
The Takeaway
MCP achieved something genuinely impressive, becoming a de facto standard backed by every major AI company within 16 months. But adoption and fitness for purpose are different things. The protocol was designed for a simpler era, and the world moved faster than the spec.
The developers fleeing to plain APIs and CLIs aren't anti-innovation. They're pro-reliability. They've seen the context window bills. They've debugged the 3 AM crashes. They've read the security advisories.
MCP isn't dead. But its 2024 design needs to become a 2026 protocol or the ecosystem will simply route around it.
Build your agents to be protocol-agnostic. Wrap your tools behind clean interfaces. If MCP matures, plug it in. If it doesn't, you've lost nothing.
The best infrastructure is the kind you can replace.`
Top comments (0)