Everyone Scrambled to Ship MCP Servers. The Agents That Actually Work Just Use the Command Line.
The AI tooling debate that's splitting the industry — and what it means for your agent setup.
Everyone scrambled to ship MCP servers. The agents that actually work just use the command line.
When Anthropic announced the Model Context Protocol, the industry did what the industry does: panic-shipped implementations. Every SaaS company, every dev tool, every startup with an API - they all rushed to build MCP servers. Proof they were "AI first." Proof they got it.
Except now the cracks are showing.
A blog post titled "MCP is dead. Long live the CLI" hit 339 points on Hacker News last week. The comments section was brutal. And the same week, Google quietly launched WebMCP - a completely different vision of how agents should talk to the web.
The industry isn't just debating this. It's splitting.
The case against MCP (and it's stronger than you'd think)
Here's the thing about LLMs: they already know how to use command-line tools.
They've been trained on millions of man pages, Stack Overflow answers, and shell scripts. When you tell an agent to run gh pr view 123, it just works. No special protocol needed. No initialization dance. No JSON transport layer to debug at 2 AM.
Eric Holmes put it bluntly: "MCP solved a problem that didn't exist."
And his arguments are hard to dismiss:
→ Debuggability. When your agent does something unexpected with a CLI tool, you can run the same command yourself and see exactly what it saw. Same input, same output. With MCP, you're spelunking through protocol logs.
→ Composability. CLIs pipe. They chain through jq, grep, redirect to files. Try analyzing a large Terraform plan through MCP — you're either blowing up the context window or building custom filtering into the server itself. The CLI version? One line: terraform show -json plan.out | jq '.resource_changes[] | select(...)'
→ Auth that already works. AWS uses profiles and SSO. GitHub uses gh auth login. Kubernetes uses kubeconfig. Battle-tested flows that work whether you're at the keyboard or an agent is driving. MCP reinvents this wheel — and the new wheel is worse.
→ No moving parts. CLI tools are binaries on disk. MCP servers are processes that need to start, stay running, and not silently hang. One of these is fundamentally more reliable than the other.
But the web doesn't have a command line
Here's where it gets nuanced.
Google just launched WebMCP early preview — a way for websites to expose structured tools to browser agents. Declarative APIs for HTML forms, imperative APIs for complex JavaScript interactions.
The use case is different. When an agent needs to book a flight or file a support ticket through a website, there's no CLI to fall back on. The DOM is messy. Screen scraping is fragile. Having websites explicitly declare "here's how to interact with me" makes sense.
This is where MCP-style protocols earn their keep: bridging the gap between agents and interfaces that were designed for humans, not machines.
The mistake isn't the protocol itself. It's applying it everywhere, including places where simpler tools already work.
What this means in practice
We've been running agent setups for dozens of teams at this point, and the pattern is clear:
For anything that touches servers, code, infrastructure, or data — CLI tools win. They're faster to set up, easier to debug, and they compose in ways that MCP simply can't match.
For browser automation and web interactions — structured protocols like WebMCP will eventually win. But that "eventually" matters. The spec is in early preview. Production-readiness is months away, probably longer.
For everything in between — be pragmatic.
The teams that waste the most time are the ones who pick a side religiously. "We're all-in on MCP" or "MCP is dead, CLI only." Both positions lead to pain. The right answer is boring: use the tool that fits the job.
The real lesson
The best agent tooling is the tooling that works for both humans and machines.
CLIs have had 50 years of design iteration. They're composable, debuggable, and they piggyback on auth systems that already exist. That's not an accident — it's the result of millions of developers iterating on the same basic interface.
MCP is less than two years old. It'll get better. WebMCP might genuinely change how agents interact with the web.
But right now?
If you're setting up an agent and the tool you need has a CLI — just use the CLI. Your agent already knows how. And when something breaks at 2 AM, you'll be able to debug it like a human, not like a protocol engineer.
→ Start with CLIs for infrastructure, code, and data tools — your agent already speaks bash fluently.
→ Watch WebMCP for browser automation — the vision is right, but the spec isn't ready yet.
→ Don't pick a religion — pick what works for the specific tool and use case.
The agents that ship aren't the ones with the fanciest protocol stack. They're the ones that actually work.