From "Full MCP" to "Rediscovering the Shell"
In the second half of 2024, the community once believed that MCP would integrate tools to unify the world. Each service should be packaged as an MCP server, each agent host should support MCP, and each workflow should be completed through MCP tool calls. I also followed the trend and installed a bunch of them - GitHub MCP, Playwright MCP, Memory MCP, Sequential Thinking, Context7, Exa, Firecrawl...
But after half a year, a trend is very clear: inDaily workflow of coding agentHere, the tools that are really used every day and are used to the end are almost not MCP, but CLI. Bash by Claude Code,gh,git,kubectl,rtk,cmux, these are the main axes of daily productivity.
This is not "MCP failure" (Anthropic also donated MCP to Agentic AI Foundation at the end of 2025, and ChatGPT/Cursor/Copilot all joined in support, which is obviously continuing to expand). butUse agent to write programs for developersIn this scenario, the tool design pendulum has indeed swung towards CLI. Here are five reasons I compiled myself.
Reason 1: You can’t escape context tax (under default implementation)
The default behavior of most MCP hosts is to preload the prompt/tool context of each tool description, parameter schema, and return format description on the server.Regardless of whether this conversation will call. Anthropic's own document states that "MCP tool definitions may occupy a considerable proportion of the context"; Playwright officials also directly admit that MCP mode tokens are more expensive.
This situation has begun to be solved recently: Anthropic launchedMCP tool search, when the tool definition exceeds the threshold, it is changed to deferred loading; GitHub MCP and Playwright MCP have also added a "reduce context" flag. But these are new features, not default and not supported by all hosts.
So in practice it is still:Hang up a few MCP servers and pay thousands to tens of thousands of tokens in taxes before writing anything.. CLI tools are completely unnecessary -gh pr listYou don’t have to tell the model in advanceghWhat is it? There are already tens of millions of them in the training data.ghExample, the model can be used by itself.
(Rough personal experience: A medium-sized MCP server has about 5-10K tokens, and 5 stacked up to 30-50K. This is an order of magnitude based on feelings, not a tested fact, please use it as a reference.)
Reason two: CLI output can be intercepted and filtered, and MCP return is difficult
The return from the CLI is a plain text stream, which can be concatenated with filters:
rtk git log
rtk gh pr view 123
gh pr list --json title,state | jq '.[] | select(.state=="OPEN")'The reason why RTK can achieve the effect of "Claude Code saves 50% tokens" is that the CLI output can be intercepted, compressed, and rearranged before entering the agent context.
MCP is not incapable of post-processing - MCP spec allows text, image, audio, resource link and other content blocks, and Claude Code also providesPostToolUseHook can intercept MCP tool results. But these are the respective extension points of host/server, and they do not have the combinability of Unix pipe that "can naturally be used one line after another". I have seen a Playwright snapshot in which 5000 lines were directly poured into the context. At that time, I could only pray that the hook would block it first.
Reason three: CLI is truly portable in "agent that can run shell"
same onegh pr create, I can run it in Claude Code, Codex CLI, Aider, Cursor agent, Cline, and Continue.dev. The instructions remain unchanged, and the agent can be replaced by anyone.
(A common mistake I make: ChatGPT’s Code Interpreter/Data Analysis is a Python sandbox, not a shell.ghIt cannot run there, so this rule only applies to "agents that can actually execute shells." )
MCP configuration is relatively fragmented. Claude Code can indeed import Claude Desktop settings; Cursor CLI and editor share MCP settings; Cline CLI and VS Code extensions also share. butAcross different vendorsStill have to do one each - the config file location, installation path, and environment variables are all different. To move the entire MCP between Claude / Cursor / Cline / Codex, it is almost necessary to reconfigure it once. For people who "want to use the strongest agent to solve the toughest problems", CLI is still a more portable tool language.
Reason Four: Debugging Transparency
When there is a problem with the CLI, I can see the complete trace: command line, stdout, stderr, exit code, all left in the terminal log.
When there is a problem with MCP, it is often necessary to compare both sides: does the tool return an empty array? Is it because the server didn't catch it, or is there a schema parsing error, or is there a timeout on the host side? Usually you need to check the host console and add the server side log.
When agent autonomous runs for eight hours in the middle of the night, this transparency gap will be magnified: in the CLI failure mode, the agent can fix it by reading stderr by itself; in the MCP failure mode, the agent often can only give up or retry until it is tired.
Reason 5: Delay
Many MCP servers are stdio subprograms or containers. Each first call requires handshake and initialization; the remote MCP also requires HTTP/SSE. A warm shell, or a compiled binary (like RTK), makes "quick lookup" requests an order of magnitude faster.
For agents, this gap is not only speed, but also the cost threshold of "whether you are willing to check it lightly" - cheap tools will be used more often, and expensive tools will be gradually avoided.
So where is MCP still alive? (actually quite a few)
I'm not advocating for unplugging MCP altogether. It is still strong in these types of scenarios:
Stateful session: Playwright MCP maintains the browser process, retains cookies and page state. It doesn't make sense to redo it with the CLI.
structured data: Tree-like data of knowledge graph and accessibility snapshot are more suitable for MCP content block than plain text.
Strict permission boundaries: When you need to explicitly control what the agent can do (not allowing arbitrary shell execution), MCP's tool whitelist is safer than open Bash.
Resources and prompts: MCP spec provides resources (content readable by the agent) and prompts (preset request templates), which is where the CLI has no corresponding structure.
Remote OAuth service: For SaaS such as Linear, Notion, and Atlassian, which have formal OAuth processes, the MCP connector is much cleaner than letting the agent handle token refresh by itself.
Discovery for non-project users: Connect Google Calendar to Claude Desktop and press a button to use it. For non-programming users, MCP's GUI/menu is much friendlier than CLI.
There’s also an in-between design: Anthropic’sAgent Skills. Skills also has the discovery of MCP (the list can be seen in the system prompt), but the skill content will be lazy-loaded during execution. In the end, Bash/CLI is still used to run the work, which is equivalent to "MCP's discovery convenience + CLI's execution cost."
Practical advice: start with subtraction
If your current Claude Code (or other agent) has a bunch of MCPs hanging, I would recommend:
See which MCPs are actually being used and which ones are just burning context.
Unplug all MCPs that are "used less than once a month".
For things that can be replaced by CLI (GitHub, archives, grep, git), use CLI + filter (RTK and the like) instead.
What remains: browsers, structured data, permission boundaries, remote OAuth, organization sharing integration.
My own settings were reduced from about 12 MCPs to 4. The agent is smarter, responds faster, and the context can withstand long sessions.
Conclusion: The pendulum has swung to the middle
This is not an "MCP fails" story, but more like the tool design pendulum swinging back from "all-in MCP" to the middle. After all, LLM is a species that has read several megabytes of shell commands. If you give it a terminal, it can use the entire Unix ecosystem; if you give it an MCP, it can use the few tools you installed - two levels of abstraction, each with its own suitable scenarios.
For coding agents, the future looks like:CLI is used as the main course, Skills is used as index, and MCP is used as special purpose. The craze that "everything is MCP" has receded to a more reasonable position.