Why MCP Was Always a Bad Idea?

This article boldly declares the Model Context Protocol (MCP), once lauded for AI-agent interaction, is now obsolete thanks to smarter LLMs. The Hacker News community fiercely debates whether direct API interaction is truly superior or if MCP still offers crucial security and control advantages. Prepare for a spirited defense of a protocol many thought was yesterday's news.

Score

Comments

#14

Highest Rank

on Front Page

First Seen

Sep 21, 1:00 AM

Last Seen

Sep 21, 10:00 AM

Rank Over Time

The Lowdown

The author argues that the Model Context Protocol (MCP), initially a cornerstone for enabling LLMs to interact with external services, has become an outdated concept. While MCP saw rapid adoption after its 2024 launch by Anthropic, its inherent limitations have been outpaced by the rapid advancements in large language models.

MCP was designed for earlier, less capable LLMs to access external tools, leading to an 'MCP Industrial Complex' where numerous servers added to 'context bloat' for agents.
Modern LLMs are now sophisticated enough to execute code, reason about large codebases, and discover and interact directly with HTTP APIs and CLIs (e.g., using --help to understand commands).
The article advocates for deprecating MCP, suggesting that instead of an intermediate protocol, agents should leverage existing internet standards like HTTP APIs and CLIs.
To facilitate this, the author proposes standardizing how agents use HTTP APIs directly, such as using specific Accept headers (e.g., text/markdown) or Accept-Language headers for preferred programming languages in documentation.

The core message is that the increased autonomy and intelligence of contemporary LLMs render the intermediary layer of MCP unnecessary, urging a shift back to more direct, standardized communication methods.

The Gossip

MCP's Enduring Utility

Many commenters vigorously defend the continued relevance of MCP, arguing that the article misses its crucial value beyond just direct API interaction. They highlight MCP's role in providing granular control over external service access, handling authentication securely without exposing API keys to the agent, offering a sensible UI for connecting services, and ensuring strong audit logging. Some shared positive experiences with MCP for specific applications (like Power BI authoring) and noted its effectiveness in wrapping APIs for agent consumption or integrating internal tools in sandboxed environments, especially where full terminal access for an LLM is undesirable or insecure. The argument is made that MCP simplifies agent interaction and provides a standardized layer that abstracts away complexity and enhances security.

The Case Against MCP

Conversely, a segment of the discussion strongly supports the author's critique, asserting that MCP is indeed a flawed or unnecessary abstraction. Critics argue that MCPs are limited, prone to errors, and lead to 'token burn' at runtime due to their verbosity and inefficient processing, especially when a deterministic program using a direct API could achieve the same outcome more efficiently. Some contend that MCP never made sense due to poor design, high token costs, and significant security risks (e.g., exposing sensitive data if not properly secured), particularly with the advancements in LLM security capabilities.

Standardization Squabbles

The proposed solutions for direct API interaction, particularly the suggestions around HTTP headers, sparked considerable debate. Many commenters pushed back against the idea of 'abusing' existing HTTP headers like `Accept-Language` to convey programming language preferences. They argued that such practices deviate from established RFCs and create confusion, advocating instead for proper standardization processes through committees or simpler, more explicit methods like using different URLs for language-specific documentation (e.g., `/docs/python/`). The core tension here is between pragmatic, rapid-fire solutions for LLMs and adherence to long-standing internet standards.

CLI vs. Direct API for Agent Efficiency

A common thread of discussion revolved around the optimal interaction method for LLM agents: CLIs or direct HTTP APIs. Some argued that LLMs are surprisingly good at figuring out CLIs, especially when the feedback loop is faster. One commenter described a 'tool wrapper' that captures CLI output to save tokens by intelligently truncating and allowing expansion. However, others pointed out practical challenges, such as SaaS providers rarely offering CLIs for their extension APIs and the potential performance overhead of repeatedly spawning processes for CLI calls versus stateless HTTP requests. The debate underscores the evolving understanding of how LLMs best interact with the broader digital ecosystem.