Why MCP Was Always a Bad Idea

MCP was designed in late 2024 to let language models reach external services, and it quickly became widely adopted as models and agentic workflows were still immature. That success produced a proliferation of MCP servers, each exposing multiple tools and schemas, which created severe context bloat for models. Engineering workarounds - centralized credential stores and minimal tool sets from platforms like Composio, MintMCP, and Pipedream - helped in the short term, and whole stacks arose to monitor servers, validate responses, and present usable schemas. Those fixes papered over the protocol’s limits rather than solving them.

Models have since grown capable of writing and running scripts, reasoning about large codebases, and calling unfamiliar APIs and CLIs directly; Cloudflare’s Code Mode shows how LLMs can safely compose calls into executable scripts. Because most MCP servers merely wrap existing HTTP APIs or CLIs, the sensible move is to retire most of them and standardize agent-first use of HTTP and CLIs. Practical steps include agent-identifying headers and content negotiation (Accept: text/markdown) and using Accept-Language to indicate a preferred programming language for docs - practices already appearing in documentation sites and Shopify. The conclusion: prefer direct, standardized HTTP/CLI interfaces and end-of-life MCP.