The MCP vs CLI Debate Is Missing the Point

Six months ago, MCP was the future. Every vendor shipped an MCP server. Every conference talk mentioned Model Context Protocol. If you weren't building MCP integrations, you were behind.

Now the pendulum's swung. CLI tools are the thing. "Just use bash." "MCP is overhead." "Why wrap an API in JSON-RPC when curl exists?" A post called "MCP is Dead; Long Live MCP" hit the Hacker News front page today with 70 points and climbing.

I've built production MCP servers, benchmarked them across four languages, and built a security firewall for the protocol. I also use CLI tools in my agent workflows daily. The debate as framed is wrong.

The question nobody's asking

The MCP vs CLI argument treats this as a protocol choice. It isn't. It's a knowledge distribution problem.

When your agent runs git log --oneline -20, it doesn't need a schema. It doesn't need a tool description. The model saw millions of git commands during training. It knows the flags, the output format, the error patterns. One shot, correct invocation, minimal tokens.

Same for curl, jq, grep, psql, aws s3. These tools live in the training data. The agent already speaks them fluently.

Now try this: your team built an internal API last Tuesday. It handles inventory allocation across three warehouses with custom business rules. The agent has never seen this API. It doesn't know the endpoints, the auth flow, the request shapes, or the error codes.

With a CLI wrapper, the agent needs to discover usage through --help, descend through subcommands, figure out parameter formats, and hope the help text is good enough. Multiple turns. Progressive context loading. And if the help text is ambiguous (it always is), the agent guesses wrong and you debug for an hour.

With an MCP tool, the schema lands in context on the first turn. Input types, required fields, descriptions. The agent knows exactly what it can call and exactly what shape the request needs to be. One turn to correct invocation.

The real question: does the model already know the tool, or does it need to learn it at runtime?

CLI wins where training data wins

This is the part the MCP defenders get wrong. For tools the model already knows, MCP adds pure overhead.

An MCP tools/list response dumps every tool schema into the agent's context window before a single tool gets called. If you've got 30 tools registered across 3 servers, that's thousands of tokens consumed before any work happens. For an agent that just needs to run grep -r "TODO" src/, that's wasted context.

Claude Code figured this out early. It doesn't use MCP for git operations. It shells out. git diff, git log, git status. The model knows these commands better than most developers do. Adding an MCP layer would mean loading tool schemas that describe functionality the model already has internalized.

The token math is real. An MCP tool declaration for a simple search function runs 150-300 tokens. The equivalent CLI invocation might be 20 tokens total. When you're running 30 tool declarations per session, that's 5,000-9,000 tokens of pure overhead. On a 200K context window that's not catastrophic, but it's not free either. Especially when those tokens could hold actual code or documentation.

For well-known tools: skip MCP. Use the CLI. The model already speaks it.

MCP wins where nobody talks about it

Here's where the "MCP is dead" crowd loses the plot entirely. They're thinking about local stdio MCP, which wraps a single tool on a developer's machine. That use case is genuinely weak for known tools.

Server-side MCP over Streamable HTTP is a completely different animal.

I run MCP servers that multiple agents hit concurrently. Different developers, different agent runtimes, different sessions. The server holds database connections, API keys, cached state. The agents connect over HTTP with OAuth tokens. They don't need local credentials. They don't need the API keys. They don't even need to know which database holds the data.

Try doing that with a CLI tool. Every developer needs the API key. Every machine needs the client library installed. Every agent runtime needs the right binary for its platform. State doesn't persist across sessions. Auth credentials scatter across laptops and CI runners. Someone leaves the team and you're hunting for every place they copied an API key.

Centralized MCP solves this the same way any server solves it. One deployment. One auth layer. One place to rotate secrets. Standard OAuth revocation when someone leaves.

But the advantages go beyond auth.

The parts nobody mentions

MCP isn't just tools. The spec defines three primitives: tools, resources, and prompts.

Resources let the server expose structured data that the agent can pull into context without a tool call. Think of it like a read-only data feed. Your MCP server can expose a config://production/feature-flags resource that agents read before making decisions. Or docs://api/v3/changelog so agents always have the latest API changes without you updating every AGENTS.md file across 15 repos.

Prompts are reusable prompt templates served by the server. Your team defines a code-review prompt that enforces your org's review standards. Every agent, regardless of which developer is running it, gets the same review criteria. Change the prompt on the server, every agent picks it up next session. No PRs to 15 repos updating CLAUDE.md files.

Nobody talks about resources and prompts in the MCP vs CLI debate because most people only ever used MCP tools. The protocol is doing more than they realized.

Observability you can't get from bash

When your agent runs curl to hit an internal API, what telemetry do you get? Whatever your API server logs. Which agent called it? Which developer's session? What was the prompt that led to this call? You don't know.

A centralized MCP server can emit OpenTelemetry traces for every tool invocation. Which tools get used. Which fail. Which take too long. Which agents use which tools. You get org-wide visibility into how AI agents interact with your infrastructure.

I didn't appreciate this until I was debugging why an agent kept hitting a rate limit on a third-party API. With CLI tools, I'd be grepping through terminal logs across multiple machines. With the MCP server, I opened Grafana and saw the spike in 30 seconds.

The actual decision framework

Stop asking "MCP or CLI?" Start asking these:

Does the model already know this tool? If yes, use the CLI. git, curl, jq, grep, docker, kubectl. Don't wrap known tools in schemas.

Did your team build this tool? If yes, MCP is probably better. The agent needs the schema to use it correctly. You'll save turns and reduce errors.

Do multiple developers or agents need this tool? Centralized MCP over HTTP. One deployment, one auth layer, one telemetry pipeline.

Does the tool need secrets? MCP server. Keep credentials out of developer machines and CI environment variables.

Is this a one-off script? CLI. Don't build an MCP server for something you'll run three times.

What I actually run

My production setup uses both. CLI for everything the model knows: git, file operations, shell utilities, package managers. MCP for everything my team built: custom search tools, database queries with specific business logic, third-party API integrations where I want centralized auth and rate limiting.

The MCP servers run over Streamable HTTP. Agents authenticate with OAuth. Tools emit OpenTelemetry traces. I can see which tools get used, by whom, and how often. When I need to rotate a third-party API key, I change it in one place.

The CLI tools just run. No schemas. No servers. No overhead. The model knows grep better than I do.

This isn't MCP vs CLI. It's knowing when each one is the right tool, which is the kind of judgment call that makes engineering harder than coding. We don't need another protocol war. We need better instincts about when a problem needs structure and when it doesn't.