Everyone is wiring MCP servers into their agents. I am increasingly convinced that for most real work, it is the wrong tool. Not because MCP is bad, but because a wrapped CLI does the same job cheaper, faster, and with far less pain.
Start with cost. An MCP server loads its whole surface into the agent's context. Every tool, every schema, dumped into the token budget whether the agent uses it or not. Then each call routes through extra layers. I have watched the same data fetch cost twenty cents through MCP that would cost a penny through a direct API hit. When you are running these things at volume, that gap is the whole game.
Now the developer experience. Building an MCP server means building the API and then building the MCP layer to hit the API. Testing it is awkward. You are debugging a protocol on top of a service. Compare that to a CLI: if you can feed a framework an API interface or an OpenAPI spec, it wraps the whole thing into a command in minutes. Testing is stupid easy. And critically, it runs local. The agent calls it like any other bash tool. A CLI invocation and a bash tool call look nearly identical to the model, so you are working with the grain of how coding agents already operate.
The objection is that the agent will contrive twenty layers of nonsense to use a CLI. In practice it does not, as long as you pair the CLI with a skill that gives it a little help output and the CLI itself has clear --help text. The agent checks, learns, and proceeds. This is the same reason skills are software, not markdown - the real leverage is in the executable wrapper, not the prose.
The deeper point is that agents can do anything Python can do. Once you accept that, the question stops being "which MCP do I install" and becomes "what is the cheapest deterministic path to this result." Most of the time, that path is a local command, not a protocol. If you are still treating MCP as the default integration layer, you may be paying a tax for the privilege - and most APIs are not even ready for agents yet anyway.
Key takeaways
- MCP loads the full tool surface into context and costs more per call than a local CLI doing the same job.
- Wrap an API in a CLI, pair it with a skill for usage hints, and the agent treats it like any other bash call.
- Testing a CLI is trivial; testing an MCP server means building the API, then building the MCP to hit the API.
FAQ
Why is a CLI cheaper than an MCP server?
An MCP server loads its entire tool surface into the agent's context window and routes calls through extra layers. A CLI runs locally as a bash call, with help output the agent can check on demand, so it does not burn tokens just to know the tools exist.
How does the agent learn to use the CLI?
You pair the CLI with a skill that provides a little help guidance, plus the CLI's own clear help output. The agent quickly checks usage and proceeds, the same way a developer reads --help before running an unfamiliar command.
Sources
Related Essays
Agents Are Software, Not Prompts
The industry treats agents as a new category. They are not. Agents are software, and the same engineering principles that have always mattered still apply.
Sessions Replace Tasks, Runs, and Threads
When the same object has three names, your architecture is drifting. Tasks, runs, threads, chats — all of it is just a session. One container, many shapes of work.
Automating Knowledge Work Is Software Engineering
Automating your GTM motion, vendor onboarding, or SKU rationalization is software engineering. The end user being internal does not change the discipline required.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.