Maharshi Patel spent a day at a conference about MCP and came away wanting the whole layer gone. MCP — the Model Context Protocol — is the standard Anthropic shipped in November 2024 so AI agents could plug into outside services and data; it is how an agent gets a “tool” it can call. His argument is a timing one: it was designed for models that were not yet good at the job themselves, and those models no longer exist. The 168-comment thread on Hacker News mostly agrees with the diagnosis and rejects the prescription.

What the protocol cost, on Patel’s reading:

  • Every MCP server arrives with tools, each carrying its own schema. Add enough of them and they overload the model’s context window — the working memory a conversation has to fit inside.
  • The ecosystem’s answer — credential hubs such as Composio, MintMCP and Pipedream that expose one small tool set — works, but he calls it “good, for the short term.”
  • Meanwhile the models learned to write and run scripts, reason across large codebases, and call APIs they have never seen. They also learned --help: they can discover a command-line tool’s interface by asking, so many MCP servers simply wrap something that already existed.
  • Cloudflare’s Code Mode keeps MCP but changes its shape — the model composes calls into a script that runs in a sandbox instead of making one trip to the server per tool.

His prescription is to delete most MCP servers and standardize how agents use plain HTTP APIs. The example he points at already works: content negotiation, where a server honors Accept: text/markdown and returns Markdown instead of HTML. A Vercel engineer proposed agents declare their preferred programming language in the Accept-Language header so documentation sites serve relevant examples; Shopify shipped it.

The essay’s claim is that MCP is “a protocol of a bygone era” — scaffolding that outlived the limitation it was built for — and should be end-of-lifed in favor of HTTP APIs and CLIs where they exist.

What the thread adds

  • simonw — the four things MCP still does that “just let it call APIs directly” does not: “Control over exactly which external services it can access… A way to handle authentication that doesn’t allow the agent to directly access API keys… A sensible UI to allow users to connect and authenticate further services… Strong audit logging.” His framing is that the advice is fine “if you are running a full-blown terminal agent… with unfettered internet access” — and that this is not the only thing people want to build.
  • prescriptivist — the enterprise shape of exactly that: a fleet of sandboxed coding agents sharing files through MCP tools over a virtual filesystem. The agents “don’t know the files are on AWS,” cannot see the credentials, and every request is logged by the orchestrator outside them.
  • CharlieDigital — MCP looks pointless “in solo mode,” where your secrets are local and nobody audits anything. The case for it is teams: rotating secrets when someone leaves, shipping to many runtimes, and the fact that “protocols almost always win.”
  • jvanderbot — the unintended win. Plenty of companies had no API and no reason to build one; now they do, “so more companies now allow me access to my own data on their platform.”
  • thehamkercat — the same effect for people who never touch a model: sites exposed MCP servers because it was fashionable, and those servers can be driven by ordinary automation.
  • cagz and AndrewDucker — both land on the assumption buried in “delete the servers”: an agent you are willing to hand free rein to. A narrow, purpose-built endpoint can enforce limits that the underlying API does not.
  • mbreese — a correction aimed at the essay’s own proposal: do not repurpose Accept-Language. “These things are well defined for a reason and redefining things isn’t helpful.”
  • fg137 — the piece re-argues ground HN covered long ago; “the author did not bother to just look them up before posting these uninformed opinions.”

The question the article leaves open

“Agents with terminal access can replace most MCP servers” drew the same objection from several directions at once: what about agents that have no terminal, or should not have one? docheinestages asks it plainly, gmueckl calls terminal access “a potential violation of least privileges,” and simonw’s list is the practical version of the same complaint. The essay’s answer — give the agent a shell and a documented API — is exactly the configuration those commenters are unwilling to run. Nobody in the thread resolved it; several are running MCP anyway.

On reading comments as evidence: HN handles are pseudonymous and the site publishes no per-comment scores, so the ordering is HN’s own ranking, not a vote. This is a slice of the thread, not a consensus.