The Fix for MCP Is a CLI

Every new integration shows up as an MCP server now. Want your agent to touch GitHub, your database, the design tool, the ticket tracker? There’s a server for it, and the pitch is always the same: install it, point your agent at it, done. I kept installing them. And I kept noticing that for most of what I actually do, I’d rather just give the agent the command-line tool it already knows.

For something like 99% of cases a CLI beats an MCP server, and the gap is not close. MCP has a real place. It’s a lot smaller than the hype suggests.

The argument

A few things hold this up.

Agents already know CLIs. git, gh, curl, jq, rg, psql: these have been in the training data for years, with millions of examples of correct usage. The model knows the flags, the output formats, the common pipelines. An MCP tool is a brand new interface it has never seen, described to it once, in the current context window. One of these is a language the agent is fluent in. The other is a phrasebook you hand it at the door.

CLIs compose. The Unix tools chain. You pipe gh into jq, filter, sort, hand the result to the next thing, all in a single line that runs in the shell and returns only what you asked for. MCP tools are islands. Each call is its own request and its own response, and every intermediate result has to travel back through the model before the next step can run.

There’s nothing to run. An MCP server is a process. You start it, keep it alive, update it, authenticate it, and debug it when it falls over. A CLI is a binary already sitting on the machine. The agent calls it the same way I would.

Tool definitions aren’t free. This is the part people skip. Every MCP server loads its tool definitions into the context window up front, before the agent has done anything. A handful of servers and you’ve spent tens of thousands of tokens just describing what’s available. Anthropic, who created the protocol, published a post on exactly this: moving from loading every tool definition to having the agent write code that calls tools on demand took one workflow from 150,000 tokens to 2,000. A 98.7% drop. The fix for MCP’s context cost is to stop front-loading tools and let the model reach for them as code.

In practice the difference is plain. Say I want the open pull requests I opened:

gh pr list --json number,title,author | jq '.[] | select(.author.login == "vsanka14")'

One line. It runs in the shell, filters in the shell, and hands the model back five rows instead of fifty. The MCP version is a server running in the background, a tool schema sitting in context, and the full result set flowing through the model so it can do the filtering itself. Same answer, more moving parts, more tokens.

Where MCP earns its place

Less than you’d think. The usual case for it is “this service has no CLI,” but most of those services are a plain HTTP API, and curl reaches an API fine. The agent knows curl too. “There’s no command for it” is rarely the real problem.

The one place I’d actually reach for MCP is a stateful session: live state on the other side that has to survive between calls. A browser the agent drives across a whole task, a database connection, a REPL. Playwright is the clearest case. It isn’t wrapping a REST endpoint, it’s exposing a running browser the agent snapshots, clicks, and types into, call after call, against one session. There’s nothing stateless to curl there, because the session is the point. That one holds up.

What I ask now

I’m not against MCP servers. When I need it I reach for it, and it does the job. But the default has drifted. The question I ask now isn’t “is there an MCP server for this,” it’s “is there already a tool the agent knows.” Most of the time there is, and reaching for it is the simpler, cheaper, faster thing to do.