Why agents want a CLI, not an MCP

The CLI does the work

Watch an agent build something and notice what it reaches for. It runs a command, reads the output, runs the next one. The command line is where the work happens. So that is what I build for.

There are three reasons, and none of them are taste. The first is token cost. An MCP server announces every tool it has, with full schemas, every time it loads. That sits in the context window whether the agent touches those tools or not. A CLI announces nothing. The agent runs --help when it wants help and pays for those tokens once, when it needs them, not on every turn for the life of the session.

The second is composability. CLI tools pipe into each other. The agent can chain them, filter the output, loop over a list, do the same dozen things a developer does at a terminal without me having designed for any of it in advance. An MCP tool does the one thing its schema describes. The moment the agent wants a combination I did not anticipate, it is stuck waiting for me to ship a new tool.

The third is the plainest one. The model already knows how to use a command line. It read every man page and every Stack Overflow answer on Earth. I do not have to teach it git or grep or my CLI once my CLI behaves like the others. I get to lean on everything it already learned instead of inventing a new surface it has never seen.

Where MCP and skills actually belong

MCP is good. I am not against it. The right place for it is a production server: a real REST or HTTP service, with logging, with pricing, with the things a server needs to be a server. If you are exposing a capability to the outside world over a wire, MCP earns its weight. As the interface for my own development loop, I do not reach for it. Those are different jobs, and I keep them different.

Skills sound better than they work. The honest test is to watch one run. A lot of the time, when a skill needs to do something on GitHub, it calls gh. It was a wrapper around the thing that was already on the machine. The skill did not add a capability. It added a layer between the agent and a CLI that the agent could have run on its own.

A skill earns its keep when it encodes workflow that a command cannot: the order to do things in, the conventions that are not written anywhere, the five steps you would otherwise repeat by hand every time. That is real, and that is what a skill is for. But a skill that only routes to a command line is a tax. Skills mostly become necessary when the only available door is an MCP, and that is its own annoyance, not a point in their favor.

Build the CLI first, let the agent borrow it

Here is the structure I believe in. AGENTS.md is the lay of the land, the street signs that orient an agent the moment it arrives. Skills can point the way when there is real workflow to point at. The CLI tools are what the agent picks up and uses to do the work. Three layers, and the abstraction stays thin on purpose. Let the code carry the in-between instead of stacking another wrapper on top of it.

The bigger principle underneath all of it: AI should use the command line for development, the same command line a human uses. When I build a tool for myself, I am building the tool the agent will borrow. Build the CLI first. Make it good for the person in the seat. The agent gets a tool that already works, and I never had to build it twice.