DEV Community

Cover image for Everyone Scrambled to Ship MCP Servers. The Agents That Actually Work Just Use the Command Line.
Octomind.dev
Octomind.dev

Posted on • Originally published at octoclaw.ai

Everyone Scrambled to Ship MCP Servers. The Agents That Actually Work Just Use the Command Line.

#ai #automation #devops #opensource

TL;DR:

  • CLI tools are more reliable and effective for tasks involving servers, code, and infrastructure.
  • MCP protocols may fit specific cases around web automation but aren't ready for prime time yet.
  • Flexibility is key: choose tools based on what works best for your use case.

Everyone scrambled to ship MCP servers when Anthropic announced the Model Context Protocol. The industry rushed to prove they were "AI first," but the cracks are beginning to show.

Check out the blog post “MCP is dead. Long live the CLI” that blew up on Hacker News. It's clear the excitement is turning into skepticism, especially with Google quietly launching WebMCP, a totally different direction for how agents interact with the web.

The Case for the CLI

Here’s the deal: LLMs already know how to use command-line tools. They’ve been trained on countless man pages and shell scripts. So when you tell an agent to run gh pr view 123, it just works. No special protocols or debugging at 2 AM required.

Eric Holmes hit the nail on the head: "MCP solved a problem that didn't exist."

Consider these points:

  • Debuggability: If an unexpected result occurs, running the same command yourself gives you the same context — no spelunking through logs like you would with MCP.

  • Composability: CLI tools chain together seamlessly. Need to analyze a large Terraform plan? With CLI, it’s just one line:

  terraform show -json plan.out | jq '.resource_changes[] | select(...)'
Enter fullscreen mode Exit fullscreen mode

Good luck doing that easily with an MCP setup.

  • Proven Auth Flows: AWS, GitHub, and Kubernetes have reliable, existing authentication systems. MCP tries to reinvent this wheel — and it’s not as robust.

  • Reliability: CLI tools are standalone binaries, meaning fewer moving parts compared to the processes MCP servers require.

Enter WebMCP

But here’s a twist: Google recently rolled out WebMCP. This is more suited for web tasks where no CLI exists, like booking flights or submitting support tickets. A structured way to communicate with messy DOMs makes sense here, and protocols like WebMCP are designed for those interactions.

The real issue? Applying MCP everywhere, even in scenarios where CLI tools are a better fit.

Practical Takeaways

From our experience running agent setups for various teams, here’s what you should consider:

  • Use CLI tools for everything that involves servers, code, or data. They’re quicker to set up and easier to debug.
  • For web interactions? Keep your eye on structured protocols like WebMCP. They’re promising, but still not production-ready.
  • Stay pragmatic — don’t get too entrenched in one approach like “MCP is the future” or “CLIs are the only way.” Flexibility is crucial.

The takeaway? The best tooling is what works for both humans and machines. CLIs, with their decades of fine-tuning, are designed to be composable and debuggable. MCP will improve, and WebMCP might transform agent interactions over time, but for now?

Stick with the CLI when you can. Your agent already speaks bash, and troubleshooting will be a lot easier when something goes wrong.

  • Start with CLIs for anything involving infrastructure, code, or data — they’re tried and true.
  • Keep an eye on WebMCP for future web automation.
  • Avoid tool dogma — use what fits the job best.

What’s your experience been? Are you leaning toward MCP, CLIs, or a mix of both? Drop a comment — I'd love to hear what’s working for you.

This article was originally published on OctoClaw. Read the full breakdown on the OctoClaw blog.

This article was originally published on OctoClaw. OctoClaw provides turnkey cloud-hosted OpenClaw instances — up and running in minutes, no self-hosting pain.

Top comments (0)