This article explains why AI agent tool calling is shifting from MCP to CLI. MCP provides a standardized protocol, but it introduces context bloat, complex execution chains, and security risks. CLI improves reliability and cost efficiency through on-demand discovery, pipeline composition, and a mature ecosystem. Keywords: MCP, CLI, AI Agent.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Source language | Chinese |
| Related languages | Shell, JSON-RPC |
| Interaction protocols | MCP, JSON-RPC, CLI standard input/output |
| Article type | Technical perspective and tooling practice summary |
| Mentioned tools | gh, mcpkit, unmcp, Claude Code |
| Core dependencies | GitHub CLI, Node.js, uv/uvx, MCP Server |
| Reference platforms | GitHub, Claude Code, internal enterprise agent systems |
| Star count | Not provided in the original article |
MCP Was Once Treated as the Standard for AI Tool Integration, but Its Costs Are Now Becoming Concentrated
MCP has a clear goal: package external capabilities such as file systems, databases, and the GitHub API into a unified set of tools that a model can call. It uses a client-server architecture. The client retrieves tool definitions, injects those definitions into the model context, and then lets the model decide which tool to invoke.
AI Visual Insight: This diagram shows the basic MCP invocation chain. The server first exposes
tools/list and the parameter schema, the client then injects the tool metadata into the model context, and after the model outputs a tool call, the server executes it and returns the result. Its defining characteristic is that tool definitions enter the context before any actual invocation happens.
The problem starts there. MCP turns standardized integration into an advantage, but also turns context overhead into a systemic cost. For agents, the more tools you connect, the heavier the initial context becomes, leaving less room for actual task reasoning.
# A typical MCP interaction can be abstracted into two phases
# Step 1: List all tool definitions
client -> server: tools/list
# Step 2: After the model decides, call a specific tool
client -> server: tools/call {"name":"search_repositories","arguments":{"query":"agent"}}This flow shows that MCP is not primarily about direct execution. Its core pattern is to fully expose tool descriptions first, then let the model choose within the context.
MCP’s Core Weakness Appears First in Its Uncontrolled Context Cost
In multi-server scenarios, tool definitions, descriptions, and parameter schemas can quickly consume tokens. The original article cites a case where connecting only three MCP servers can consume roughly 143K tokens in tool definitions alone, which is close to 72% of a 200K context window.
AI Visual Insight: This image emphasizes that MCP injects large volumes of tool documentation into the context during initialization, effectively pre-spending the available reasoning budget. The visual focus is usually the oversized share of the context window occupied by tool definitions, illustrating the problem of “tokens exhausted before execution begins.”
When irrelevant tool descriptions occupy the context, the model’s attention to task goals, user intent, and key constraints becomes diluted. This not only increases cost, but also reduces tool-selection accuracy, creating a classic form of context rot.
MCP’s Complex Architecture Increases Both Reliability and Authentication Costs
MCP involves model reasoning, protocol translation, server lifecycle management, network requests, and downstream service dependencies. The longer the execution chain, the more failure points you introduce. Initialization failures, dirty state, and repeated authentication are all common issues.
AI Visual Insight: This figure highlights how MCP spans multiple execution boundaries: the model, client, server, remote services, and authentication systems are all chained together. If any node fails, the entire workflow can break. Troubleshooting this architecture usually requires analyzing logs, network behavior, and permission states at the same time.
# In a multi-tool environment, developers often need to authenticate each tool separately
gh auth login # Authenticate GitHub
some-mcp-tool auth # Authenticate a specific MCP tool
another-tool login # Log in to another service againThis example shows that authentication often cannot be abstracted into one unified layer. In practice, operational overhead can easily exceed the cost of the tool invocation itself.
MCP’s Security Issues Are Not Isolated Bugs but Architectural Exposure
The original article mentions three representative risks: indirect prompt injection, tool poisoning, and rug pull attacks. Together they point to one fact: when tool discovery and invocation depend on dynamic exposure, remote registration, and model decision-making, the attack surface expands significantly.
In addition, publicly exposed MCP servers introduce authorization gaps and access-control problems. For enterprises, that means the question is not just whether MCP can be integrated, but whether it remains governable after integration.
CLI Is Becoming the Preferred Interface for Agents Again Because It Better Matches How Models Work
CLI’s advantage is not novelty, but maturity. It compresses tool capability into commands, arguments, input/output, and exit codes. That makes it naturally suited to incremental exploration and step-by-step execution, rather than forcing the model to absorb every tool definition upfront.
CLI Significantly Reduces Context Pollution Through On-Demand Discovery
An agent does not need to preload an entire tool catalog. Like a human operator, it can first inspect help output, then drill into subcommands, and finally execute a specific task. This progressive discovery model is more token-efficient than MCP’s full injection approach and much closer to how real systems are operated.
AI Visual Insight: This diagram typically illustrates CLI’s layered exploration path: read the top-level help first, locate the relevant subcommand next, and add parameters only when needed. The technical emphasis is that knowledge unfolds by layer rather than through full pre-injection, which substantially lowers context usage and reduces selection errors.
# Discover command capabilities first
gh --help
# Then inspect parameters for a specific subcommand
gh pr --help
# Finally execute the target operation
gh pr list --state open --json number,titleThese commands reflect the core advantage of CLI: information expands on demand, so the model can explore and act at the same time.
CLI Provides Native Composability Through Unix Pipes
The command line does more than execute actions. It can directly compose data-processing workflows. Compared with MCP, which often requires additional code for post-processing, CLI can handle filtering, transformation, and aggregation through standard output and pipes alone.
AI Visual Insight: This visual highlights the chained processing model of shell pipelines: one command’s output becomes the next command’s input, creating a low-coupling, observable, and easy-to-debug data flow. This pattern is especially well suited for agent automation.
gh pr list --state open --json number,title,author \
--jq '.[] | select(.title | test("bug")) | "\(.number) by \(.author.login)"'This command filters pull requests whose titles contain bug and outputs the PR number along with the author, demonstrating CLI’s unified support for querying and post-processing.
MCP, CLI, and Skills Solve Three Different Layers of the Problem in Practice
| Dimension | Skills | MCP | CLI |
|---|---|---|---|
| Problem solved | Tell AI what it should know | Tell AI how to connect tools | Tell AI how to execute |
| Primary form | Markdown/rule files | JSON-RPC protocol and server | Commands, arguments, stdout/stderr |
| Token cost | Very low | High | On-demand loading |
| Debuggability | High | Low | Very high |
| Security governance | Easy to control | High risk | Mature |
These three are not mutually exclusive. A more accurate model is this: Skills provide behavioral instructions, CLI handles execution, and MCP standardizes interoperability. Enterprises should combine them based on task frequency, cost sensitivity, and governance requirements instead of treating them as a single-choice decision.
CLI and Bridge Tools Form a More Practical Path for Real-World Deployment
For GitHub, cloud platforms, databases, container orchestration, and similar scenarios, CLI already has a mature toolchain. LLM training data also naturally includes a large volume of Shell documentation, so models usually understand git, curl, docker, kubectl, and gh better than custom tool schemas.
# Install GitHub CLI
brew install gh
# Authenticate with GitHub
gh auth login
# Query the number and title of open pull requests
gh pr list --state open --json number,title --jq '.[] | "\(.number): \(.title)"'This command set shows how an agent can use an existing CLI to perform real business operations directly, without first building an additional MCP integration layer.
If you already have investments in the MCP ecosystem, you do not need to abandon them entirely. mcpkit can convert an MCP server into a CLI command surface, while unmcp offers a lighter-weight terminal invocation model. This allows teams to preserve existing assets while gaining CLI’s low-context advantages.
# Install mcpkit
npm install -g @balakumar.dev/mcpkit
# Install the GitHub MCP Server as a CLI tool
mcpkit install "npx -y @modelcontextprotocol/server-github" --name github
# Invoke the tool through the CLI surface
mcpkit call github search_repositories '{"query":"mcpkit"}'This example shows that the value of the bridge layer is not replacement. It is restructuring MCP assets into an interface that agents can consume more efficiently.
When Enterprises Embrace CLI, They Are Choosing a Lower-Friction Execution Plane for Agents
The release of official CLIs from platforms such as Feishu, Google Workspace, and Zilliz reflects the same judgment: if AI is going to participate in real business workflows, the most important question is not whether the protocol is elegant, but whether execution is stable, controllable, and cost-efficient. CLI aligns more closely with engineering reality on all three points.
So the more reasonable conclusion is not that MCP is dead. It is this: use CLI first for high-frequency tasks, low-latency tasks, and composable tasks; continue using MCP for complex cross-system integration and standardized shared capabilities; and rely on Skills to provide organizational knowledge and execution rules to the agent.
FAQ
1. Has MCP lost its value?
No. MCP still fits scenarios that require a unified protocol, cross-platform tool sharing, and multi-agent collaboration. It is simply not a good fit for pushing large volumes of high-frequency execution tasks into the context.
2. Why is CLI more friendly to LLMs?
Because CLI supports on-demand discovery, standard input/output, exit codes, and pipeline composition. In addition, model training data naturally contains a large amount of command-line documentation and scripts, which lowers the learning cost.
3. If we already built an MCP ecosystem, do we have to refactor everything?
Not necessarily. You can first use bridge solutions such as mcpkit and unmcp to convert existing MCP servers into a CLI invocation surface, then gradually evolve toward a hybrid architecture that combines CLI, Skills, and MCP.
Core summary: This article systematically breaks down the differences between MCP and CLI in AI agent scenarios. MCP is strong in standardized integration, but it faces context bloat, complex execution chains, and architectural security exposure. CLI stands out with on-demand discovery, composability, debuggability, and operational maturity. Combined with bridge solutions such as mcpkit and unmcp, it provides a pragmatic path for enterprises deploying agent toolchains.