MCP is Dead. Long Live the CLI.
Two months ago, Eric Holmes declared the end for MCP. Because LLMs are already proficient with the command line, adding a protocol layer was seen as completely redundant.
After all, MCP has its own issues: token costs, servers freezing on startup, OAuth authentication pop-ups appearing repeatedly, and an all-or-nothing permissions model. Pretty much everyone emphatically agreed with Eric's perspective.
Then this week, Anthropic published a long blog post: "Building Agents That Reach Production Systems with MCP." The title doesn't say it outright, but the translation is: You were right to criticize us, we've made changes, and we've figured out what MCP is actually supposed to do.
Eric's Reasons for Declaring MCP Dead Were All Valid
Large models are inherently skilled with CLI; they don't need MCP.
If a CLI command fails, running the same command in the terminal shows identical output. But if MCP throws an error, the logs are another story entirely.
CLI also has mature Unix pipe composition capabilities. Chains like grep | jq | awk are extremely convenient and not something an MCP server can easily replicate.
But Anthropic Says: You're Only Seeing Half the Picture
Anthropic breaks down the paths for agents connecting to external systems into three categories:
Direct API Calls: Fine for simple scenarios, but after a dozen integrations, the M×N combinatorial explosion becomes unmanageable for anyone.
CLI: Extremely powerful locally. But it has one fatal limitation: cloud agents, mobile agents, and web agents don't have a shell.
MCP: A standardized protocol with built-in authentication, service discovery, and rich semantics. It's designed for production-grade cloud agents.
The key point is the second one.
When an agent only runs in your terminal—for example, Claude Code assisting you locally with coding—CLI is the optimal solution. There's no debate there. But what about agents running in the cloud? In a browser? On a phone?
Claude now has Cowork (cloud collaboration) and Managed Agents. These don't live in your Mac terminal; they require a standardized way to connect to external systems. And CLI simply cannot run in these environments.
MCP wasn't created to replace CLI. It's here to cover the areas where CLI cannot reach.
Once this positioning is clarified, most of the previous arguments essentially resolve themselves.
Technical Improvements
This time, Anthropic presented several improvement plans for MCP.
Tool Search — On-Demand Tool Loading
One of the most criticized issues previously: a server registers a bunch of tools, all schemas are crammed into the context window, and when too many tools exist, the token count explodes.
The new approach is on-demand searching—dynamically loading required tools based on user intent, and not loading irrelevant ones at all.
The result: Token consumption for tool definitions was reduced by over 85%.
Programmatic Tool Calling — Process in a Sandbox First, Then Return
Another pain point: After an agent calls a tool, the raw JSON is dumped entirely back into the context, flooding it with large amounts of junk information that consumes tokens. The new solution performs filtering and aggregation within a code sandbox first, supplying only useful information to the model.
The result: Token consumption for complex workflows was reduced by approximately 37%.
Skills + MCP = A Shell
Skills teach the agent "how to do something" (procedural knowledge), while MCP gives the agent "what tools to use" (tool access). The two are packaged together and distributed as a plugin.
For example: A K8s operations plugin: Skills contain troubleshooting workflows and best practices, MCP provides kubectl tools. Install it, and the agent is ready to work.
In the future, MCP servers can even come with their own Skills; clients automatically gain operational knowledge upon connection.
300 Million Downloads Per Month. And You Say It's Dead?
A statistic mentioned in the blog—MCP now sees over 300 million downloads per month.
Despite the criticism, its user base continues to grow.
Ultimately, the facts speak for themselves. CLI is indeed more comfortable for local scenarios. But when your agent needs to go to the cloud, operate cross-platform, or connect to a dozen SaaS services, there is no better standardized choice than MCP.
It's somewhat reminiscent of the old REST vs. GraphQL debate. When GraphQL first appeared, it was also criticized: "HTTP is enough, why build something so complex?" The outcome? For complex scenarios, those who needed it, used it.
Final Thoughts
Looking at the outcome, the "MCP is dead" debate was a good thing. It forced Anthropic to clarify its positioning:
MCP isn't a cure-all; it's a standardized connectivity layer for production-grade cloud agents.
For local scenarios, use CLI as you see fit; no one is stopping you.
Sometimes, a technological solution facing fierce community skepticism isn't necessarily a bad thing. It's certainly better than building in a vacuum where nobody uses it.