Over the last year, debates about agent toolchains have increasingly centered on one question:

Does MCP (Model Context Protocol) make tool calling simpler, or does it make simple tasks more complex?

For most day-to-day engineering tasks, CLI is becoming the more practical default.

Cost gap is not a UX issue, but an order-of-magnitude issue

The biggest practical pressure in MCP is token overhead.

In common scenarios, MCP often has to load large tool schemas before actual execution. Using a GitHub MCP Server as an example, initialization alone can consume tens of thousands of tokens. For long tasks, this directly squeezes context budget.

Community benchmarks keep pointing to the same conclusion:

• Single MCP calls commonly cost several to dozens of times more than CLI
• Retry recovery is also more expensive (reconnect plus context reload)

This is not just “a little slower.” It scales into API cost, latency, and reliability issues.

Why models are naturally better at CLI

A frequently overlooked fact is training distribution.

LLMs have seen massive amounts of terminal text during training: commands, outputs, errors, scripts, and man pages. In other words, CLI interaction is already close to the model’s native input pattern.

By contrast, MCP’s JSON-RPC and tool schema style became widespread only in recent years. Models can learn it, but familiarity and compression efficiency are often still weaker than long-established CLI patterns.

That also explains why, in many cases:

• for the same goal, CLI commands are shorter
• outputs are easier to continue reasoning over
• error recovery paths are more stable

Security and isolation: MCP still has catching up to do

MCP is not incapable of security, but its ecosystem is still early.

Common concerns today include:

• Tool Poisoning in descriptions
• behavior drift (Rug Pull)
• same-name tool override (Shadowing)

CLI also has security risks (injection, privilege misuse, path risks), but its process model, permission boundaries, and audit chain have been validated through decades of engineering practice. In production, that predictability matters.

This does not mean MCP has no value

I do not think MCP should be abandoned.

A more reasonable positioning is:

• CLI handles the execution layer (local, low-latency, high-frequency calls)
• MCP handles the connection layer (remote service discovery, unified auth, audit, and multitenancy)

That is the commonly discussed hybrid architecture: CLI + MCP Gateway.

When integrating many remote systems and enforcing unified governance and compliance, MCP still has clear value. But for helping agents complete engineering work quickly, CLI-first usually better matches current model capability boundaries.

In today’s engineering reality, CLI is closer to an agent’s working native language; MCP is better positioned as a connection protocol rather than the only execution protocol.