Is MCP a Bad Idea? A Keep, Fix, or Drop Test for Tool Servers

No, MCP is not a bad idea, but the essay making that case right now lands one real blow: piling more tools into an agent session does degrade performance, and at least one independent paper puts a number on the limit. The evidence supports fixing your MCP deployment, not deleting it, with a five-tool budget per session, a twelve-month migration clock, and a narrow pilot for the essay’s terminal-access alternative.

What the essay actually argues

An essay titled “Why MCP Was Always a Bad Idea,” published September 14, 2026, states its thesis bluntly: MCP is “a horrible protocol built for a time when LLMs weren’t that smart, and we’ve outgrown it”. The essay recounts the protocol’s history (released by Anthropic in November 2024, donated to the Linux Foundation’s Agentic AI Foundation in 2025) and then makes three testable claims.

First, a mechanism claim: context bloat. As the author puts it, “users started to add many MCP servers to their setups, and they started running into the context bloat issue. Each server would come with multiple tools, each with its own schema, which started to overload the context of all of these models.” Second, an obsolescence claim: modern LLMs can discover command-line tools through the --help command, so they no longer need MCP servers to access many services available through documented APIs or CLIs. Third, a prescription: “We delete most of our MCP servers. That’s it. Agents with terminal access can replace most MCP servers and often are more capable”.

Each of these is worth testing rather than accepting or dismissing, because all three are author-reported observations that no independent source has replicated. What follows is a claim-by-claim check against the published record.

Tool sprawl: the one claim with independent support

The context-bloat mechanism has a partial corroboration, and it comes from an unexpected direction. A recent preprint on NemotronLabs VoiceChat, a full-duplex speech-to-speech model, reports that “performance can degrade when many tools are exposed, with a practical recommendation of no more than five tools per session”. That is an author-reported result from one team, on one model, in a voice workload that looks nothing like a text-based coding agent. But it is the only independent quantitative check on the essay’s central mechanism, and it points in the essay’s direction: more exposed tools, worse tool use.

This finding changes the economics of tool-server investment regardless of where the exact threshold lands for your stack. It breaks the comfortable assumption that connecting another MCP server makes an agent more capable. If performance degrades with tool count, then the bottleneck moves from server coverage to curation: which five tools does this agent actually need for this session, and who maintains the descriptions that determine whether it picks the right ones? Groundy’s earlier look at when gating external evidence helps agents found the same direction from a different angle: curated tool selection beat maximal exposure on an unchanged agent.

The practical consequence is that tool count becomes an operational budget, like memory or latency, rather than a feature checklist. A hypothetical deployment with forty tools across twelve servers is not “more integrated.” On the available evidence, it is likely worse, and the fix is gating and session scoping, not deletion.

Session state: the spec moved first

Critiques of MCP’s session model have a shelf-life problem. According to Wikipedia’s protocol entry, the revision that MCP’s maintainers finalized on July 28, 2026 “removes protocol-level session tracking, making MCP stateless at the protocol layer: information about protocol version, client identity, and capabilities is instead carried in a _meta parameter with each request.”

That matters for the keep/fix/drop decision in two ways. First, any architectural objection premised on MCP requiring protocol-level session tracking is stale; the failure mode has been engineered away at the spec level. Second, it creates real work for teams with existing servers: if your implementation assumed stateful session semantics, you have a migration to plan, and per-request _meta metadata is where protocol version, client identity, and capabilities now live.

The same revision also deprecated sampling (letting a server request a completion from the client’s model) and roots (letting clients indicate relevant file-system locations to a server). Per the same entry, “deprecated features remain functional for a minimum of twelve months.” That is a dated obligation on your calendar, not an abstract concern: any server relying on sampling or roots needs a replacement path inside that window, and the clock has a firm start. The revision was finalized on July 28, 2026, a date the protocol’s own documentation, versioned 2026-07-28, corroborates, so the twelve-month minimum runs to approximately July 28, 2027.

Access surface: --help versus a versioned tool schema

The essay’s most aggressive claim is that terminal access replaces tool servers outright, because LLMs can now read --help output. The essay cites no benchmark for this claim; none of the sources cited here tests it, so treat it as untested. The claim is plausible for a specific class of server: the thin wrapper that re-exposes a well-documented CLI as three tools with shallow schemas. For that class, the server may genuinely be an extra translation layer, and translation layers are where drift accumulates. Groundy’s comparison of MCP and native function calling documented how a schema re-expressed across layers becomes a divergence point, and when tool descriptions stop matching the code behind them, agents act on the description anyway.

But --help discovery has costs the essay’s framing skips. A tool schema is a contract: typed arguments, a stable name, a description a team maintains and versions. A --help page is documentation written for humans, parsed opportunistically, with no validation of what the model extracted from it. For servers that expose data and workflows rather than CLI flags (a ticketing system, an internal knowledge base, a deployment pipeline), the schema is the governance surface. Deleting the server does not remove the need for that surface; it moves it into an unmonitored prompt-parse loop.

The honest verdict on this claim is “untested, worth a bounded pilot.” If you have thin CLI-wrapper servers, run the essay’s replacement on those, measure task success against the MCP version on your own workload, and keep whichever wins. That is a two-week experiment, not an architecture decision.

What deliberate data scoping looks like

The strongest argument for keeping MCP servers is one the essay does not engage with at all: a server is a place to enforce what an agent can see. Microsoft’s Learn MCP Server is the cleanest documented example. Microsoft states that “the MCP server contains publicly available documentation, not training or user profile information.” That single sentence is a data-exposure policy, expressed as an architectural boundary. Terminal access has no equivalent: an agent with a shell sees whatever the shell’s credentials can reach, and scoping that means managing filesystem and credential permissions the agent can reason around, rather than a schema it cannot.

For any server that mediates access to internal data, this gating function is the reason the server exists. Dropping the protocol because thin wrappers are redundant would throw out the servers doing the most valuable work.

The keep, fix, or drop rubric

Compressing the evidence into the decision the essay forces:

The verdict: fix on a budget and a clock

Fix, don’t drop. Keep MCP servers that expose data and workflows behind versioned tool schemas, because the schema is the contract and the gating surface. Cap the tools any single agent session can see near the five-tool budget the VoiceChat paper recommends, adjusting from your own measurements since that figure comes from a speech model, not a coding agent. Plan two dated migrations: to the stateless _meta request model, and off sampling and roots before the deprecation window closes around July 28, 2027. And pilot the essay’s terminal-access replacement, but only against thin CLI-wrapper servers, where the schema layer is thinnest and the claim is most plausible.

The essay’s “delete most of our MCP servers” verdict is a single author’s account of a single team’s setup. It is a useful provocation and a poor migration plan.

What remains unmeasured

Three gaps should discipline how confidently you act on any of this, including the rubric above. First, the entire drop case rests on one essay; its context-bloat and --help claims are author-reported and unreplicated, full stop. Second, the only quantitative support for a tool budget comes from one full-duplex speech-to-speech model, a workload far from typical MCP deployments, so five tools per session is a starting hypothesis to measure against, not a specification. Third, the enterprise record is volumetric rather than behavioral: Salesforce reported 4.5 million MCP calls processed on its Headless 360 platform by late May 2026 (Wikipedia), which establishes adoption but not how agents behave in production.

What the published record does settle is narrower and more useful: the essay’s mechanism is real enough to budget against, the spec is revising away its own structural weaknesses faster than critics can cite them, and the decision that matters is not whether MCP was a bad idea in November 2024 but which of your servers earn their schema maintenance today.

Frequently Asked Questions

How many tools should be exposed per agent session to avoid performance degradation?

performance can degrade when many tools are exposed, with a practical recommendation of no more than five tools per session