CLI vs. MCP: Execution vs. the Capability Manual
If you've been using AI Coding Agents like Claude Code, Codex, or Cursor recently, you've probably noticed a phenomenon.
On one hand, MCP is getting hotter, with various platforms providing MCP Servers.
On the other hand, many platforms are also starting to launch their own CLIs, even prioritizing building a CLI over MCP.
At first, I always had a question:
Isn't MCP the standard protocol for Agents? Why is everyone still spending effort on building CLIs?
Later, after actually doing AI coding for a while, I realized I had misunderstood it from the start.
CLI and MCP are not capabilities at the same layer, nor will one replace the other.
They solve two different problems.
Let's first look at how an Agent works
Many people encountering an Agent for the first time always think it is "calling tools."
But if you observe the execution process of Claude Code, you'll find it's more like a developer.
For example, you say:
Help me start the project.
Claude will likely execute:
pnpm install
pnpm dev
You say:
Check the recent commits.
It executes:
git log
You say:
Help me run the tests.
It executes:
pnpm test
The entire process is almost always:
Read information
↓
Execute command
↓
Observe result
↓
Proceed to the next step
If you open the terminal, you'll find Claude spends most of its time interacting with the Terminal.
This is also why more and more platforms are starting to build CLIs.
Because for an Agent, the CLI is no longer just a developer tool, but a natural working interface.
CLI is more like "executing tasks"
The biggest characteristic of a CLI is its simplicity.
The Agent doesn't need to know what the underlying API looks like.
It doesn't need to worry about request addresses, authentication methods, or parameter concatenation.
It just needs to execute:
platform deploy
Or:
platform app create
The CLI handles authentication, parameter validation, request sending, and then returns the result to the Agent.
The whole process is almost indistinguishable from a developer typing commands in the terminal themselves.
For tasks where you already know what needs to be done, this approach is very efficient.
But CLI has an inherent problem
Suppose you give an Agent a new CLI.
company-cli
Inside, there are dozens of commands:
deploy
rollback
logs
project
member
permission
pipeline
...
Here comes the problem.
How does the Agent know:
- What commands are available?
- What each command does?
- Which commands should be used in combination?
- Which capabilities are suitable for the current task?
Of course, it can execute:
company-cli --help
Or:
company-cli deploy --help
Exploring step by step.
But this exploration itself has a cost.
Especially when the CLI is complex enough, the Agent needs to constantly query help documentation, read output, and then decide the next step.
This is where the value of MCP shines
Many articles like to say:
MCP is a protocol.
But I think, from a developer's perspective, it can be understood more simply.
MCP is more like a capability manual.
It tells the Agent in advance:
What capabilities I have.
What each capability does.
What parameters are needed.
What results are returned.
In other words.
CLI focuses more on:
How to execute.
MCP focuses more on:
What capabilities are available to execute.
Token Cost
After truly starting AI coding, I've become increasingly concerned about another issue.
Context.
Suppose a platform provides 100 Tools.
Each Tool has:
- Name
- Description
- Parameters
- Schema
- Examples
All of this content eventually enters the model's context.
The more Tools there are.
The longer the Context.
The higher the Token consumption.
Especially in long conversations or complex workflows, this cost is not insignificant.
But the CLI's approach is completely different.
The Agent doesn't need to know all capabilities in advance.
When needed, it executes:
company-cli --help
Or:
company-cli project list
To get the currently needed information.
In other words.
MCP is more like:
Placing a manual on the table in advance.
CLI is more like:
Flipping through the manual when needed.
Neither is absolutely better.
They are just two different design philosophies.
So when is CLI suitable?
If the Agent already knows what task it needs to complete.
For example:
- Deploying an application
- Viewing logs
- Creating a project
- Downloading a file
- Publishing a version
In these scenarios with very clear objectives.
A CLI is often sufficient.
The Agent directly executes the command.
Reads the result.
Proceeds to the next step.
The entire chain is simple and stable.
This is why many platforms now prioritize providing a CLI.
Because it can serve both developers and Agents directly.
And when is MCP more suitable?
If the Agent is facing a platform with very complex capabilities.
For example:
- Hundreds of business interfaces
- Multiple resource objects
- Multi-step workflows
- The Agent needs to autonomously plan an execution path
In this case, just providing a CLI might not be enough.
Because the Agent first needs to understand:
What capabilities do I have?
Which capability is more suitable for the current task?
How should these capabilities be combined?
MCP can reduce the Agent's understanding cost in such scenarios and make it easier to complete complex planning.
Final Thoughts
I increasingly feel now that.
CLI and MCP are not really two competing products.
They are more like capabilities at two different levels.
One is responsible for execution.
One is responsible for description.
In the future, the form of many platforms will likely be:
CLI is responsible for getting things done.
MCP is responsible for making it easier for the Agent to know what things can be done.
For simple tasks, the Agent can directly call the CLI.
For complex tasks, MCP can help the Agent make better plans.
The two do not replace each other, but play roles at different stages.