MCP Is Dead
This post dives deep into the shortcomings of the Model Context Protocol (MCP) for LLM tool integration, highlighting its context consumption and reliability issues while advocating for CLI-first or 'Skills' approaches. It's popular on HN because it offers a critical, practical perspective on an emerging AI-dev standard. However, some discussion questions the article's timeliness, as recent updates may have addressed its core complaints.
The Lowdown
The article 'MCP is dead' presents a critical analysis of the Model Context Protocol (MCP), a method for connecting Large Language Models (LLMs) to external tools like GitHub, Linear, and Slack. While initially hailed as the 'USB-C of the AI ecosystem,' the authors argue that in practice, MCP suffers from significant drawbacks that hinder developer productivity and LLM efficiency.
Key issues identified include:
- Context Window Bloat: MCP tool definitions consume a substantial portion of the LLM's context window (e.g., 10.5% for Claude's 200K window with Quandri's stack), even if only a few tools are actively used. This reduces space for actual task-relevant information.
- Low Operational Reliability: MCP introduces problems like initialization failures, repeated re-authentication, slower AI responses due to external round-trips, mid-session tool crashes, and opaque permissions.
- Overlap with Existing CLI/API: The authors contend that Command Line Interfaces (CLIs) and traditional APIs offer superior human-machine parity, composability (e.g., with pipes), easier debugging, and leverage existing training data (man pages, StackOverflow), making them often more efficient.
As alternatives, the article proposes a CLI-First Strategy—allowing LLMs to directly use existing CLIs—and a Skills Pattern, where tool definitions or CLI instructions are loaded into context only when needed, like 'asking the librarian for only the book you need.' This 'Skills' approach significantly reduces context consumption compared to MCP's always-loaded definitions. While acknowledging MCP's utility in specific cases (e.g., when no CLI exists, for non-developers, or for critical database access requiring query safety and credential protection), the authors conclude that for most developer workflows, 'Skills' combined with CLIs offer superior efficiency and debuggability, freeing up significant context tokens and improving reliability.
The Gossip
Timeliness and Technical Tweaks
Many commenters immediately question the article's relevance, pointing out that Claude Code (and potentially other LLM platforms) has already implemented 'Tool Search with Deferred Loading' which significantly mitigates the 'context window bloat' problem (Problem 1) that forms a core part of the article's argument. They suggest the measurements are outdated and the update note in the article is an attempt to retroactively address this. There's a feeling that the article might be 'old news' or 'AI slop' given these fixes.
MCP's Persistence and Practicalities
Despite the article's 'dead' pronouncement, a lively debate highlights MCP's ongoing utility and potential evolution. Commenters from OpenAI argue that MCP isn't dead because many companies are building MCP servers, often lacking existing CLIs or external APIs. They emphasize the importance of AI agents gaining access to services regardless of the underlying transport. Others acknowledge MCP's value for non-developers, unified access, or specific security needs like database query safety and credential management, even if an evolved 'Skills-on-MCP' approach might be ideal.
CLI vs. MCP Conundrums
The discussion delves into the practical trade-offs between CLIs and MCP. While the article champions CLIs for their efficiency and debugging benefits, commenters question how CLIs truly save context if an LLM still needs to 'discover' commands (e.g., via help pages), a process that itself consumes tokens. There's also skepticism about the article's internal consistency, noting that Quandri (the author) still uses MCP for services like Slack, Linear, and Notion, despite earlier criticisms. Some propose that a combination of methods, perhaps a 'RAG for MCP' or an 'mcp search and execute gateway,' could offer a hybrid solution for dynamic capability discovery without constant context overhead.