MCP is an attack surface, not a feature

Most remote-service MCP servers wrap an HTTP API that already exists. That line sits at the center of a blog post arguing that the Model Context Protocol was built for a moment that has passed, and that the right move now is to delete most of your MCP servers.

Start with the timeline, because it explains the rest. Anthropic released MCP in November 2024, a protocol for letting agents connect to external services and data sources. The models of that period were comparatively primitive. Claude Code did not exist yet, and general agentic workflows were far less reliable. Giving a model access to outside services was a real productivity jump, and adoption climbed alongside the broader surge in LLM use. Anthropic stewarded the protocol, then donated it to the Agentic AI Foundation under the Linux Foundation in December 2025.

Growth brought context bloat. Every server you add ships several tools, each with its own schema, and that all lands in the model’s context whether it gets used or not. Stack enough servers and the schemas crowd out the actual work. A layer of products grew up to manage that, including Composio, MintMCP, and Pipedream, using generic search and execute patterns that hand the agent one credential store and a minimal tool set. The post calls this useful, for the short term.

The turn in the argument is that while all of that tooling was being built, the models kept improving. They can now run code, reason over large codebases, and act autonomously. A side effect of being trained to write and run scripts is that they are good at calling APIs directly, composing several services and hitting endpoints they have not seen before with little supervision. Cloudflare leaned into this with Code Mode, released September 2025, which has the model compose MCP calls into a script and run it in a sandbox rather than invoking tools one at a time. The models have also learned to run --help to discover a CLI’s interface, which lets them drive many services with no MCP server in front of them.

Hence the prescription: delete most MCP servers. An agent with terminal access can replace the majority of them and is often more capable, the post argues, and the replacement pieces are already in place as documented HTTP APIs, standard content negotiation, and mature authentication.

The rough edge the author concedes is output format. CLIs that return JSON or XML tend to be verbose and expensive in tokens. The proposed fix is to standardize how agents talk to HTTP APIs directly: an agent client attaches a header identifying itself as an agent, and the server responds with Markdown or plain text instead of HTML or heavy JSON. Two pieces of that already exist. Text-heavy sites, documentation in particular, increasingly honor Accept: text/markdown and return rendered Markdown instead of HTML. And a Vercel engineer proposed using Accept-Language to carry the caller’s preferred programming language, so a docs site can serve SDK-specific examples; Shopify’s Tobi Lutke said it would ship in Shopify’s docs.

For anyone running agents in production, the useful read is an inventory one. Walk your MCP servers and mark the ones that only wrap an API or CLI the agent could call on its own. Those are the removal candidates, and dropping them buys back context budget and removes a moving part from the stack. The servers worth keeping are the ones exposing something a documented API or CLI does not already give you.

This is one engineer’s position rather than a settled consensus, and it is a call to end-of-life a protocol barely a year past general adoption. The concrete trend underneath it is harder to dismiss: content negotiation aimed at agents is already shipping in production docs, and a capable model with a terminal needs less scaffolding than it did a year ago.

---

Contains a referral link.