MCP Is Not Dead. You're Just Using It Wrong.

Within two weeks in early March 2026, three influential voices declared MCP broken or dead: Eric Holmes’ “MCP is dead. Long live the CLI” hit the top of Hacker News on February 28 with 400+ points and nearly 300 comments. On March 11, Perplexity CTO Denis Yarats announced at the Ask 2026 conference that the company is moving away from MCP, citing severe context window overhead — a claim reported consistently by multiple outlets including Awesome Agents AI and Repello AI, though no official transcript or video of the conference is publicly available. The same day, YC CEO Garry Tan posted on X: “MCP sucks honestly.” The backlash tells you more about who’s complaining than about the protocol.

TL;DR

• What: A coordinated-seeming backlash against MCP peaked in mid-March 2026, with Holmes, Perplexity’s CTO, and Garry Tan all going public within two weeks
• The core complaint: Tool schemas consume up to 72% of context window before any user input — a real number, but an implementation failure, not a protocol failure
• Who’s actually complaining: Solo developers and small-team builders optimizing for speed and simplicity
• Action: If you’re on a team with security requirements, don’t rip out MCP. Fix your schema loading strategy instead.

MCP Is Not Dead — What Happened

Holmes’ post argued that CLI gives agents everything MCP provides, but without the overhead: shell access, tool execution, familiar interfaces. His Hacker News thread became the canonical reference point for everyone frustrated with MCP’s complexity. The post is well-written and makes a coherent case — for a specific context that Holmes never fully acknowledges.

Perplexity’s CTO, as reported by multiple tech outlets covering Ask 2026, described a scenario where tool schemas consumed 72% of the context window before any user query arrived. Apideck quantified this pattern precisely: 143,000 of 200,000 available tokens consumed by tool definitions alone. A database MCP server with 106 tools burns 54,600 tokens just on initialization. These are real numbers from production usage. They are also a description of loading every tool schema on every session — which is the implementation equivalent of importing your entire codebase before running a single function.

Garry Tan built gstack, an open-source repository packaging his Claude Code workflow into six tools as an alternative to MCP-heavy setups. For his workflow — one developer, known tools, fast iteration — it makes complete sense.

Why This Matters

The context window problem is legitimate. If you’ve wired up a large MCP server and aren’t lazy-loading schemas, you’re paying a real tax. The critics identified a genuine pain point in how most teams implement MCP today. That part of the backlash is correct.

What the backlash misdiagnoses is the cause. The 72% overhead is not a property of the MCP protocol — it’s a property of loading all tool schemas eagerly. The 2026 MCP roadmap directly addresses this: streamable HTTP transport, .well-known metadata for server discovery (so clients don’t need to load entire manifests), lazy schema loading, and quality signals in the registry. The MCP team already knows what’s broken. The fix is in progress.

The CLI alternative trades one set of problems for another. Giving an agent unrestricted shell access eliminates the structured interception point that makes audit trails possible. There are no scoped permissions, no tool discovery, no standardized auth. CLIs also require --help flags and documentation — they’re not zero-context overhead, just different overhead. And untrusted input can prompt-inject an agent into running arbitrary shell commands. Switching from MCP to CLI doesn’t change the threat model; it removes the guardrails you had. NIST launched its dedicated AI Agent Standards Initiative on February 17, 2026, specifically because agent security is not solved — and “use a CLI instead” is not a security argument.

The adoption numbers don’t reflect a dying protocol. The MCP SDK has reached 97 million monthly downloads. There are now over 17,000 MCP servers indexed across major registries. In December 2025, MCP moved to Linux Foundation governance under the Agentic AI Initiative (AAIF), with OpenAI, Google, Microsoft, AWS, and Cloudflare as founding members. The MCP Dev Summit is scheduled for April 2–3, 2026, in New York, with more than 95 sessions from MCP maintainers and organizations running it in production.

This is not what a dying protocol looks like. This is what a protocol looks like when early-adopter frustration meets a maturing implementation reality.

The most technically interesting development in the backlash conversation isn’t the CLI argument — it’s Cloudflare’s Code Mode. Instead of exposing MCP tool-calling directly, Cloudflare’s approach generates code against typed SDKs. Their API has over 2,500 endpoints. A traditional MCP server for that surface area would consume over 2 million tokens. Cloudflare’s Code Mode collapses it to approximately 1,000 tokens — roughly a 99.9% reduction, as described in Cloudflare’s own blog post. Secondary analyses have framed this as a 244x improvement against specific baseline configurations. Either way, it’s significant. But it’s also not a replacement for MCP — it’s a smarter client-side implementation pattern that works within the MCP ecosystem.

The divide the backlash reveals is straightforward: CLI wins for solo developers who know their tools, iterate fast, and don’t need to explain their security posture to anyone. MCP wins for teams that need telemetry, scoped permissions, tool discovery, observability, and standardized OAuth 2.1 auth. Garry Tan building a CLI is rational. A team of five engineers building the same thing is reinventing MCP with worse security.

The 72% context overhead figure attributed to Perplexity’s CTO at Ask 2026 is reported consistently across multiple tech outlets — but no official conference transcript or video is publicly available. Treat the specific percentage as well-sourced secondhand, not a verified primary claim.

If you’re hitting context overhead from MCP tool schemas, the fix is lazy loading — only initialize the tools relevant to the current session. This is an implementation change, not a protocol migration. The 2026 MCP roadmap includes .well-known metadata for server discovery that makes this pattern significantly cleaner.

The Take

The people loudest about killing MCP have never had to explain to a CISO why their agent has unrestricted shell access. That’s not a criticism of their work — it’s a description of their context. Holmes is solving a real ergonomics problem for solo developers. Garry Tan built a tool that fits his workflow perfectly. Perplexity identified a real implementation failure mode.

None of that is a protocol-level indictment.

MCP is not dying. It’s going through what every infrastructure protocol goes through: early adopters hit scaling pain, vocal critics declare it broken, and the protocol team ships the fixes that were already in the roadmap. The 2026 improvements — lazy loading, streamable transport, .well-known discovery — directly address every concrete complaint the backlash raised.

The teams ripping out MCP to replace it with CLIs are optimizing for developer ergonomics at the cost of operability. That trade-off makes sense at one engineer. It stops making sense at five. Before you blow up your MCP setup based on a Hacker News thread, ask yourself which side of that line you’re on.

Related

• Best MCP Servers 2026 — Which MCP servers are worth running in production right now
• GitHub MCP Server — How GitHub’s official server handles auth and permission scoping
• OpenAI Acquires Astral: What UV and Ruff’s New Owner Means for Open Source — Another data point on ecosystem consolidation that shapes where MCP is heading