Is MCP Dead? Evaluating the Model Context Protocol vs. CLI-First Strategies
The Model Context Protocol (MCP) was hailed as the "USB-C of the AI ecosystem," promising a universal standard to connect Large Language Models (LLMs) to external tools like GitHub, Slack, and Notion. However, as developers move from early adoption to daily production use, a contentious debate has emerged: is MCP an elegant solution or an over-engineered layer that hinders performance?
Recent analysis from the Quandri engineering team suggests that for many developer workflows, MCP may be an unnecessary abstraction. By comparing MCP against a "CLI-first" strategy and the "Skills" pattern, they argue that the protocol often introduces significant overhead in terms of context consumption and operational reliability.
The Case Against MCP: Context and Reliability
The primary criticism of MCP centers on how it utilizes the LLM's context window. In a standard MCP setup, tool definitions—the schemas that tell the LLM what a tool does and how to call it—are often loaded upfront.
The "Context Bloat" Problem
Quandri's measurements reveal that tool definitions can devour a surprising amount of the context window. In their stack, connecting just four MCP servers (Linear, Notion, Slack, and Postgres) consumed approximately 21,077 tokens. For a model like GPT-4o with a 128K window, that is 16.5% of the available "desk space" gone before the actual work begins.
Linear is a particularly egregious example, where 42 tool definitions account for over 12,800 tokens. This means the model carries the weight of every possible Linear action, even if the user only needs a single get_issue call.
Operational Overhead
Beyond tokens, the architectural layer of MCP introduces several operational frictions:
- Latency: Every MCP call adds a process layer between the LLM and the API. Benchmarks have shown MCP to be significantly slower than direct REST API calls, especially during initialization.
- Reliability: MCP servers are separate processes that can crash mid-session or fail during authentication, leading to opaque errors within the AI conversation.
- Redundancy: For developers, MCP often overlaps with existing Command Line Interfaces (CLIs). If a tool already has a stable CLI, creating an MCP server often means recreating the same functionality in a less composable format.
Alternatives: CLI-First and the Skills Pattern
To mitigate these issues, some teams are adopting a CLI-First Strategy. Instead of a specialized protocol, they provide the LLM with the CLI, the API documentation, and the necessary environment variables. This approach leverages the fact that LLMs are already trained on vast amounts of man pages and StackOverflow data.
The Skills Pattern
While MCP is described as "spreading all menus on the table upfront," the Skills Pattern is akin to "asking the librarian for only the book you need."
In this model, the LLM only loads the specific instructions for a tool (e.g., a curl command for a Linear issue lookup) when that specific skill is invoked. This prevents the context window from being permanently occupied by unused tool definitions. For example, a Linear lookup via CLI might cost ~200 tokens, compared to the ~12,957 tokens required by the MCP approach.
The Counter-Argument: Why MCP Still Matters
Despite these critiques, many industry experts—including those at OpenAI—argue that the "MCP is dead" narrative misses the bigger picture. The protocol's value isn't in the transport layer, but in the standardization of service discovery.
Accessibility for Non-Developers
CLIs are powerful for engineers, but they are a non-starter for HR, finance, or marketing teams. MCP provides a way for non-technical users to connect services via a UI (like Claude or ChatGPT) without installing binaries or managing SSH keys.
Security and Guardrails
One of the strongest arguments for MCP is safety. A CLI-based agent has the power to run any command the user has permissions for, including DROP TABLE in a database. An MCP server, however, can act as a security proxy, enforcing read-only modes and validating queries at the server level before they ever reach the database.
The "Long Tail" of APIs
Not every service has a CLI. Many SaaS products only offer web interfaces or complex APIs that are not designed for LLM consumption. MCP allows these companies to build a "bridge" that makes their service agent-ready without forcing users to write custom wrapper scripts.
Synthesis: Choosing the Right Tool
The debate suggests that the choice between MCP and CLI is not a binary one, but a spectrum based on the use case:
| Scenario | Recommended Approach | Rationale |
|---|---|---|
| Local Dev / Personal Tools | CLI + Skills | Maximum speed, lowest token cost, easy debugging in terminal. |
| Enterprise / Shared Teams | MCP | Centralized auth, permission scoping, and easier onboarding for non-tech users. |
| Production Databases | MCP | Essential for query safety and access control. |
| SaaS without CLI | MCP | Only viable way to provide structured tool access. |
Conclusion
As the ecosystem evolves, the technical frictions of MCP—such as context bloat—are being addressed. Features like Tool Search with Deferred Loading (introduced in Claude Code) already reduce context usage by over 85% by loading schemas on-demand.
Ultimately, the goal is not to find a single "winning" protocol, but to optimize the flow of information. Whether through a lean CLI or a robust MCP server, the priority remains the same: minimize noise in the context window and maximize the reliability of the tool execution.