When people ask whether agents should use a CLI or MCP, they are comparing two different layers of the stack. CLI is an execution surface. It is how work actually happens inside a real environment with a current directory, environment variables, credentials, logs, and exit codes. MCP is an interoperability layer. It tells an agent what capabilities exist and how to call them in a more portable way.
That is why the debate keeps feeling confused. The best agent systems already use both. They fall back to shell commands for local, stateful, high-context work, then reach for MCP when they need a reusable contract that can travel across clients. One of the more revealing recent Hacker News threads was not about replacing the shell with MCP, but about building a universal command-line client for MCP. That is not a contradiction. It is the market telling you the shell is still the most natural landing zone for both humans and agents.
The shell keeps winning because it carries context for free. An agent can run git,
npm, kubectl, or terraform without first requiring a registry,
schema negotiation, or vendor-specific adapter.
MCP is valuable because it standardizes discovery and invocation. That makes tool access cleaner across clients, but it does not remove the messy, privileged, environment-bound layer where work ultimately gets done.
In developer workflows, the shell is hard to beat because it inherits the exact world the agent is operating in. The checked-out branch, the local cache, the container runtime, the cluster auth, the failing test output, the current repo root — all of that already exists at the command line. A generic tool contract can expose pieces of that context, but only after someone decides which pieces matter and re-models them explicitly.
Current directory, secrets, SSH agents, cloud auth, local config, and stderr/stdout are already there. Agents do not need a second representation of the same reality.
If a tool has a binary, a script, or an HTTP endpoint, it can be driven from a shell. That universality is hard to match, especially in mixed stacks and messy internal environments.
When the agent fails, a developer can rerun the same command, inspect the same output, and recover from the same point. That handoff matters more than protocol elegance.
git diff --stat
npm test
kubectl logs deploy/api --tail=100
terraform plan
No registry. No capability card. No JSON-RPC handshake. Just process I/O in an environment that already knows what project, cluster, or account you are talking to. That is why coding agents and ops agents keep reaching for shells even when more structured interfaces are available.
None of that makes MCP hype fake. The official MCP introduction calls it a “USB-C port for AI applications,” and that is a useful mental model as long as you do not confuse ports with workflows. MCP matters because it gives tool builders and client builders a shared contract instead of forcing every product to invent bespoke adapters.
Anthropic's recent post about donating MCP to the Agentic AI Foundation makes the adoption story clear: more than 10,000 public servers, support across ChatGPT, Cursor, Gemini, Microsoft Copilot, and VS Code, plus a growing connector and registry ecosystem. That is not a toy. It is the beginning of a tool layer.
Agents can enumerate capabilities instead of guessing which hidden command, REST route, or browser click path exists.
One well-defined tool surface can be reused across multiple clients instead of rewritten for every IDE, chatbot, and automation product.
Agents get typed inputs and outputs instead of pretending to be a shaky human clicking through UIs and parsing screenshots.
This is exactly why WebMCP is so interesting. When a browser or app exposes real capabilities, the agent can stop acting like a remote-controlled intern clicking buttons and start interacting with actual state. That is a genuine shift.
The hardest part of agentic work is rarely “can I call a tool?” It is “which tool should run now, under what approval, with what retry policy, and how do I explain what happened afterward?” MCP does not fully answer those questions. It gives you a cleaner tool contract, not a complete theory of orchestration.
The best public evidence I have seen is Vercel's own eval story: in AGENTS.md vs Skills, passive context injection beat tool retrieval because agents often failed at the decision to invoke the right capability at the right time. Tool availability is not the same thing as tool judgment.
A schema can tell an agent how to call a tool, but not when to pause, ask a human, delegate, or prefer one path over another under ambiguity.
Production systems need to answer who touched what, which tool mutated state, and what evidence supported the result. That layer sits above raw tool invocation.
Standardized tools also standardize blast radius. The more portable the capability becomes, the more important approvals, sandboxing, and least-privilege design become.
That is also why skepticism around MCP is not irrational. Some engineers on Hacker News keep asking a fair question: if my model can already call a documented REST API, why wrap it again? The honest answer is that sometimes you should not. If you only need one tightly-controlled integration, raw HTTP or a CLI wrapper may be simpler. MCP starts paying off when compatibility across clients and environments matters more than local simplicity.
Google's A2A announcement matters because it makes the missing layer explicit. MCP is mostly about agent-to-tool communication. A2A is about agent-to-agent communication: capability discovery, task lifecycle, artifacts, status updates, and negotiation between a client agent and a remote specialist. In other words, the future is not MCP replacing CLI. It is a stack where different layers solve different problems.
The execution layer. Closest to the real environment, easiest to debug, best for local state and human takeover.
The capability layer. Best when tool discovery, typed contracts, and client portability matter more than bespoke local wiring.
The coordination layer. Handles delegation, long-running tasks, status, artifacts, and specialist agents that need to work together.
user request
↓
coordinator agent
↓ A2A / task delegation
specialist agent
↓ MCP / tool contract
tool server
↓ CLI or HTTP / real execution
filesystem, browser, database, kubectl, git
That is the architecture I would bet on. Not one protocol to rule everything, but a layered model of trust. CLI survives because it requires very few shared assumptions. MCP wins because standardized capabilities are useful across clients. A2A-style protocols rise because multi-agent systems need state, negotiation, and provenance that tool schemas alone cannot provide.
AGENTS.md or CLAUDE.md; dynamic discovery still is not the whole story.CLI stays because it is the most reliable way to execute work. MCP grows because standardized capabilities are too useful to ignore. Agent-to-agent protocols arrive because delegation needs more than tool schemas. The winner is not one interface. It is the stack that knows when to use each one.