Was MCP Always a Bad Idea? The Debate Over AI Tool Protocols

A Heated Debate Over MCP

A blog post titled "Why MCP Was Always a Bad Idea" recently sparked intense discussion on Hacker News, racking up 196 upvotes and over 150 comments. MCP (Model Context Protocol) — the bridge connecting large language models to external tools — has long been regarded as critical infrastructure for the AI Agent ecosystem since its launch. Yet this article raises fundamental questions about its design philosophy.

At the heart of the debate is a core question: in a rapidly evolving landscape of AI tool-calling, what kind of standardization protocol do we actually need? Is MCP a genuine solution, or just an over-engineered middleware layer?

What Is MCP, Exactly?

MCP is a protocol designed to standardize communication between large language models and external data sources or tools. The vision is compelling: through a unified interface specification, various AI models can access external resources — file systems, databases, APIs — in a consistent way, eliminating the need for every application to reinvent the wheel.

Conceptually, MCP aspires to become the "USB port" of the AI era — a universal plug-and-play standard. Any tool conforming to the protocol can be invoked by any MCP-compatible model, theoretically slashing integration costs and enriching the entire Agent tool ecosystem.

It's precisely this ambition for a grand unified standard that has become the focal point of criticism.

MCP was introduced by Anthropic in late 2024 and follows a client-server architecture: an MCP Host (such as Claude Desktop or various AI IDE plugins) acts as the initiator, communicating with an MCP Server via standardized JSON-RPC messages. The server then wraps access to specific resources like file systems, databases, or GitHub. Meanwhile, native "Function Calling" capabilities have long been supported by vendors like OpenAI — developers simply declare available functions as JSON Schemas in their requests, and the model returns structured call parameters, with no additional protocol layer required.

MCP's differentiated positioning lies in enabling the same tool server to be reused across different models and host applications, rather than being tightly coupled to a single model API. This "decoupling" concept is the core value its proponents champion — and the very reason critics argue it introduces an unnecessary layer of indirection.

The Core Criticism: Over-Abstraction and Complexity

The article's blunt title — "always a bad idea" — directly voices a deep-seated concern some developers hold about MCP's design direction. The high engagement on Hacker News suggests this skepticism isn't an isolated view; it resonates with the real-world experiences of many working developers.

The most common criticisms cluster around a few themes. The first is whether the abstraction layer is even necessary: when large models can already understand natural-language API descriptions, do we still need a dedicated protocol as an intermediary? Letting the model directly read OpenAPI specs or function signatures might be far simpler than introducing a new protocol.

The second concern is the imbalance between complexity and benefit. Adopting a new protocol means developers must learn new specifications and maintain new adapter layers — and in a context where AI capabilities themselves are iterating rapidly, such infrastructure investments may quickly become obsolete. The value of protocol standardization tends to emerge only when an ecosystem is mature and the pace of change has slowed.

Worth noting is that MCP's transport layer design has also drawn specific criticism. Early versions mandated stdio (standard input/output) as the local communication mechanism. While HTTP+SSE (Server-Sent Events) was later introduced to support remote servers, this came with increased configuration complexity, bringing along challenges around cross-process lifecycle management, authentication, and access control. Some developers have pointed out that, given immature security isolation, an MCP Server with file system write access could, if exploited by a malicious tool, create an attack surface far harder to audit than traditional API integrations. This makes the "over-complicated" critique not merely a matter of architectural philosophy, but a practical security concern in real deployments.

The Standardization Dilemma

Underlying this debate is a broader technical question: in a domain that hasn't yet stabilized, is pushing for early standardization a blessing or a curse?

Proponents argue that a lack of unified standards leads to fragmentation, with every vendor doing their own thing and developers exhausted by endless compatibility work. MCP at least provides a common foundation around which an ecosystem can coalesce. Critics counter that the shape of AI tool-calling is far from settled, and locking in a protocol now risks stifling innovation — binding the entire industry to a design that may not be optimal.

The sheer volume of 150+ comments makes it clear the community is far from consensus. Some affirm MCP's practical convenience from an engineering standpoint, while others challenge its fundamental justification from an architectural philosophy perspective. This divide itself signals that MCP is still in the "prove itself" stage.

Historically, similar debates have played out repeatedly in the standardization of technology. The SOAP vs. REST battle is a classic case: SOAP pursued universal interoperability through strict XML Schemas and WSDL descriptions, but ultimately lost out to the lighter REST style due to its excessive complexity. The Language Server Protocol (LSP), on the other hand, is a counterexample — it successfully unified communication between code editors and language toolchains and was widely adopted by the VS Code ecosystem, proving that "the right abstraction at the right time" can indeed foster a thriving ecosystem. MCP's supporters often cite LSP as their reference point, while critics more frequently invoke SOAP as a cautionary tale. The different historical examples each side draws on lead to diametrically opposite conclusions.

What This Means for Developers

For developers building AI applications today, this debate serves as a valuable reminder: don't blindly follow any single technical solution, even when it's being pushed hard by a major vendor.

When deciding whether to adopt MCP, it's worth asking a few questions: Does your application genuinely need cross-model, cross-tool portability? Is the maintenance overhead of introducing a protocol layer worth the payoff? Does using the model's native function-calling capabilities already meet your needs?

Technology choices are never black and white. MCP isn't necessarily a "bad idea," but it's certainly no silver bullet for every situation. What truly matters is understanding its applicable boundaries — in scenarios that require broad ecosystem interoperability, a standardized protocol has real value; but in lightweight, fast-iterating projects, an over-engineered middleware layer may do more harm than good.

Conclusion

The significance of "Why MCP Was Always a Bad Idea" may lie less in whether its conclusions are correct, and more in the open debate it has sparked about the design philosophy of AI infrastructure. In an era when AI Agent technology is advancing at breakneck speed, maintaining a critically analytical eye toward mainstream solutions is, in fact, a sign of industry maturity.

Wherever MCP ultimately ends up, this discussion reminds us: good technical standards should earn their place through the test of practice and time — not through hype and institutional endorsement.