A growing number of developers are questioning whether the Model Context Protocol, or MCP, is the right way to connect LLMs to external tools. MCP, often described as "the USB-C of the AI ecosystem" since its launch in late 2024, allows LLMs to interact with services like GitHub, Linear, Notion, and Slack. But day-to-day usage is revealing significant drawbacks.
The team at Quebec-based AI automation company Quandri decided to test the criticisms after reading a post titled "MCP is dead. Long live the CLI." Their measurements confirm the original argument: MCP consumes too much context, suffers from low reliability, and largely duplicates what existing CLIs and APIs already offer.
The case against MCP
The core complaint is that MCP eats up valuable context window space. The context window is the LLM's working desk. Every connected MCP server loads its full tool definitions continuously, even if only a handful are used regularly.
Quandri measured the tool definitions from all four MCP servers in their environment. Combined, the definitions consumed 10.5% of the total context window. Linear alone accounted for over 12,800 tokens, representing 42 tool definitions that are always present in memory, regardless of whether the LLM ever calls more than two or three of them.
Performance is another pain point. The original article benchmarked a Jira MCP server against the Jira REST API directly. MCP was 3 times slower per individual call and 9.4 times slower on the first call, due to initialization overhead. This is architectural: every MCP server inserts an extra process layer between the LLM and the underlying API. The same overhead applies to Linear, Notion, and Slack servers in Quandri's stack.
Measuring the bloat
To quantify the difference, Quandri compared the token cost of looking up the same Linear issue using MCP versus a direct CLI approach.
The CLI approach uses roughly 200 tokens total: about 50 tokens for the curl command and 150 tokens for the JSON response.
The MCP approach uses approximately 12,957 tokens. More than 12,800 tokens come from the always-loaded tool definitions, with only about 150 tokens for the actual tool call and response.
That is roughly 65 times more tokens consumed by MCP for the same task.
An update in the article notes that Claude Code has since rolled out Tool Search with Deferred Loading, which loads MCP tool schemas on-demand and reduces context usage by 85% or more. This largely addresses the context bloat problem for users on current Claude Code versions. However, the performance, debugging, and architectural arguments remain.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
The CLI alternative
The article argues that LLMs already know how to use CLIs. They have learned from man pages, StackOverflow, and documentation. A better approach is to provide the LLM with CLI commands directly, wrapped inside what Quandri calls "Skills."
If MCP is like spreading all menus on the table upfront, Skills are like asking the librarian for only the book you need. The key is embedding CLI usage instructions inside Skills. For example, a Linear Skill might contain the curl command for fetching an issue, along with the necessary API endpoint and authentication details. The Skill loads only those instructions into context when it is invoked, instead of carrying 42 tool definitions at all times.
For databases, the same principle applies. LLMs already know SQL and MongoDB queries well. A Postgres Skill can simply provide the connection string and table schema, and the LLM writes the queries directly.
When MCP still makes sense
Despite the criticisms, MCP does have advantages for certain use cases. It offers standardized authentication, built-in error handling, and built-in rate limiting. For services that have no CLI, or for teams that need uniform authentication across all members, MCP can still be useful.
Quandri uses all three approaches side by side, picking what fits each service. If a CLI already exists and authenticates locally, that is usually the lightest option. An MCP server can be helpful for services with no CLI or when centralized auth is important.
Conclusion
The team at Quandri replaced several MCP servers with Skills that wrap existing CLIs. This freed up roughly 21,000 tokens of context, removed initialization failures from their daily workflow, and kept debugging in the terminal where it belongs.
The article concludes that loading only the tools you need, only when you need them, with CLI instructions baked in, is the most efficient approach. MCP may evolve to solve these problems, but for now, Skills win.
Measurement methodology: Tool definition sizes were measured by extracting the JSON schema of each tool (name plus description plus parameters) from actually loaded MCP servers in Quandri's Claude Code environment. Token estimates use the roughly 4 characters per token heuristic. Full server estimates are extrapolated from sampled tool averages.
Related on Neura Market
- AI Tools Directory: Browse and compare AI-powered developer tools.
- Automation Marketplace: Find automation solutions for your workflow.
- Developer Platforms: Explore platforms and protocols for AI development.