The Model Context Protocol has an industrial complex, and one practitioner has had enough. In a September 14 post titled “Why MCP Was Always a Bad Idea”, the developer Maharshi argues that MCP, released by Anthropic on November 25, 2024, was a workaround for models that could not yet reason about code. Those models no longer exist. The protocol, he writes, is “a protocol of a bygone era,” and the correct move is to delete most MCP servers and let agents hit HTTP APIs and CLIs directly.

The argument is not contrarian for its own sake. It is a specific claim about a specific failure mode, and it deserves a real answer rather than a defense of the install base.

What MCP actually solved

When Anthropic shipped MCP, general-purpose agentic workflows were unreliable. Claude Code did not exist. Giving a model access to an external service meant hand-rolling a tool schema for every endpoint, and the protocol standardized that: one server, one schema, one connection. Adoption exploded alongside LLM adoption generally. By December 9, 2025, Anthropic had donated MCP to the Agentic AI Foundation under the Linux Foundation, which is the tell that it stopped being a product and became infrastructure.

Then the context bloat arrived. Every server ships multiple tools, each with its own schema, and stacking a dozen servers into one harness overloads the context window. A small industry grew up to manage the mess: Composio, MintMCP, and Pipedream now offer generic search-and-execute patterns that hold credentials in one place and expose a minimal tool surface to the agent. Maharshi calls this “a good thing, for the short term.” The qualifier is doing a lot of work.

The models learned to write scripts

Here is the part the MCP ecosystem has been slow to price in. Coding agents got good at writing and running scripts, and a side effect is that they got good at calling APIs directly. They compose services, hit endpoints they have never seen, and recover from errors with minimal user intervention. Cloudflare’s Code Mode, published September 26, 2025 by Kenton Varda and Sunil Pai, is the clearest admission of this from inside the MCP camp: it uses MCP but has the model compose calls into sandboxed scripts rather than invoking tools one at a time.

The stronger version of the argument is that agents now discover CLIs through --help and never touch an MCP server at all. Most remote-service MCP servers, Maharshi notes, ultimately wrap APIs that already exist. If the model can read the docs and write the call, the wrapper is overhead.

Most remote-service MCP servers wrap APIs that already exist. If the model can read the docs and write the call, the wrapper is overhead.

The counterargument, and where it holds

MCP is not only about tool calls. It is also about authorization, auditability, and a stable contract between an agent and a service that does not want to hand a shell to an arbitrary model. That matters more, not less, as agents get more autonomous. A harness that lets a model run curl against production is a harness with a new class of incident.

But that is an argument for better HTTP-native agent standards, not for MCP specifically. The post points at the emerging pattern: servers that honor Accept: text/markdown return rendered Markdown instead of HTML, cutting token usage on documentation-heavy sites. A Vercel engineer, Malte Ubl, asked harnesses to send the client’s preferred programming language in Accept-Language so docs sites can serve Python-specific examples instead of generic ones. Tobi Lutke said Shopify would support it, and it now ships in Shopify docs. That is content negotiation, a 1990s idea, doing the job MCP schemas were invented to do.

The unresolved problem is real: CLIs return verbose JSON and XML, which is expensive in tokens. Maharshi concedes this. But the fix is a formatting convention, not a protocol.

What this means for builders

If you maintain MCP servers, the honest question is whether you are wrapping an API that an agent could call itself. If yes, you are maintaining a schema for a model that no longer needs it. If your server adds authorization, rate limiting, or a curated tool surface that a raw API cannot express, you have a defensible product.

The bigger signal is directional. Anthropic built MCP for the models of late 2024. The models of 2026 write scripts, read --help, and negotiate content types. Infrastructure built around a capability gap tends to outlive the gap by a few years, then gets deleted. MCP is entering that window, and the Agentic AI Foundation now stewards a standard whose founding premise is quietly expiring.

Watch whether the foundation publishes a roadmap that assumes script-composing agents, or one that keeps extending the schema layer. That choice will tell you whether MCP adapts or becomes a museum piece.