MCP vs. CLI: The Complexity Question Nobody's Really Asking
The hottest debate in AI tooling this week isn't about the protocol. It's about what complexity is actually worth.
There’s a post burning up Hacker News right now with the headline “MCP is dead. Long live the CLI.”
The argument: LLMs don’t need the Model Context Protocol. They’ve been trained on millions of man pages, shell scripts, and Stack Overflow answers. Give Claude a bash shell and it figures things out. The MCP layer — the typed interfaces, the JSON transport, the auth schemes, the running servers — is complexity in search of a problem.
294 points. 198 comments. Clearly struck a nerve.
I’ve been building agentic systems for a while now. Here’s my honest read.
The MCP argument is mostly right
When Anthropic announced MCP, the ecosystem collectively lost its mind. Every company shipped an MCP server as proof they were “AI first.” There were integration sprints and engineering resources and press releases.
And the underlying question — do LLMs actually need this? — kind of got lost.
The answer, in my experience: not usually.
Give an agent access to gh, jq, curl, and a shell. It knows what to do. It’s been trained on those tools. It reads the help text. It composes commands. It figures out edge cases.
What’s the MCP layer buying you? Cleaner interfaces, typed parameters, official endorsement.
What’s it costing you? Another service to run. Another protocol to debug. Another thing your team has to understand when something breaks at 2am.
The debugging story is the whole story
Here’s the thing about agentic systems: they fail in ways you can’t predict. There’s no stack trace. No line number. The failure is probabilistic and often looks correct until you notice the output is subtly wrong.
When that happens — and it will — you need to understand what the agent saw and what it did.
With a CLI: you run the same command. You see exactly what the agent saw. Same input, same output.
With MCP: you’re spelunking through JSON transport logs. You’re reasoning about the state of a running server. You’re reconstructing what happened across a protocol boundary.
That’s not a knock on MCP’s design. It’s just physics. More layers means more places for confusion to hide.
But here’s the part the debate misses
The MCP vs. CLI argument is useful. But the real question it surfaces is bigger:
What complexity is actually worth it?
This is the question every team building agentic systems needs to be asking constantly — not just about protocols, but about everything.
Every framework you add. Every abstraction layer. Every “best practice” you pulled from a conference talk. All of it carries a maintenance cost, a debugging cost, an onboarding cost.
The cost is real even when you can’t see it yet.
I’ve watched teams build genuinely impressive agentic architectures. Multi-step orchestration. Parallel tool use. Evaluation harnesses. Observability dashboards. The whole thing.
Then I’ve watched them try to debug a weird failure six months later, when half the original team has moved on and the person on call has never touched the orchestration layer.
The impressive architecture becomes a liability.
The systems that hold up in production are almost always simpler than you’d expect. Not because the engineers weren’t smart — because they were. They knew that every layer of complexity is a future problem. They added layers only when simplicity provably wasn’t enough.
A framework I actually use
When I’m evaluating whether to add a new tool, protocol, or abstraction to an agentic system, I ask three questions:
→ Can I explain this to the person who’ll be on call when it breaks? If the answer involves “well, you need to understand the protocol first,” that’s a yellow flag.
→ Does this make failures more or less visible? More abstraction usually means less visibility. Sometimes that tradeoff is worth it. Usually it’s not.
→ Am I adding this because it solves a problem I have, or because it solves a problem I might have? Speculative complexity is the worst kind.
MCP fails questions one and two for most teams. That’s why the CLI camp keeps winning in practice, even when MCP looks better on the whiteboard.
What this means for what you build
If you’re building agentic systems right now, here’s the practical version:
Start with CLIs. Your agent probably already knows how to use them. Test it before you build something more complex.
Add structure when you have evidence you need it. Not before. The evidence is usually “we have multiple agents needing to call the same capability” or “we have strict auth requirements we can’t satisfy with direct CLI access.”
Design for the person debugging it, not the person building it. These are different people. The builder wants power and flexibility. The debugger wants visibility and simplicity.
Write it down. Every non-obvious choice should have a comment, a README section, something. The future maintainer — who might be you in six months — will thank you.
The MCP debate will keep going. New protocols will get proposed. Frameworks will come and go. The ecosystem will keep generating complexity.
Your job is to stay skeptical about which complexity is actually serving you.
Simpler is harder to sell. It’s easier to maintain.
That’s the last mile right there.