CLI vs MCP: The Surface Decides the Cost

The Bug That Made Me Build a CLI

On June 8, 2026, an agent tried to detach a task from its parent on my Takt board. It sent parent="". Takt's MCP server received arguments: {}. Again and again.

A tap on the raw request body cleared the server in five minutes: the MCP client dropped the entire arguments object whenever any single value was an empty string. That was the fourth agent-facing fault in two months. Instead of a fifth workaround, Takt got a CLI that day.

I'd love to blame the protocol for all four. I can't. Two were mine: tool names that collided (create_wiki next to wiki_create), and about 40 tools that returned JSON double-encoded inside JSON. One needed a server-side workaround for a client and framework I didn't control. Only the empty-string drop was purely the client's, and it had no workaround at all, because the arguments never reached my code.

That boundary is what the CLI replaced. With taktcli, everything between the agent's arguments and my HTTP API is code I own. Parallel agents built it the same day, and taktcli login promptly broke on first real use, because the page it pointed at didn't exist yet.

I didn't start out CLI-first. When I heard Peter Steinberger on Lex Fridman's podcast say "Every MCP would be better as a CLI", and argue that MCP fills the context with huge blobs a CLI could filter with jq, I was angry. I'd just learned how to build my own MCP servers. Then I admitted how much an agent does with gh, and how noticeably slower MCP felt. I measured Takt's MCP tool list and was shocked by its size.

So I built a theory. MCP has to stay small, or it floods the context with noise, and small means less functionality. A CLI wins by design. In October I tested it, and the evidence agreed with me about the cost and disagreed about the cause.

The Numbers Looked Like a CLI Victory

The first results looked like a landslide. Every shipped MCP server took 3-6x the calls of the GraphQL CLI baseline, on both services and both models. On GitHub with Sonnet, the shipped MCP cost 6.51x as much.

I tested four ways for agents to reach the same two APIs, GitHub and Takt: curated CLI verbs, one GraphQL query through the CLI, the MCP server as shipped, and one graphql tool behind MCP. That last one was my idea. I called it "ridiculous enough" to try. The agents got 35 read-only questions with verified answer keys, on two models, Sonnet 5.5 in Claude Code and GPT-6.1 Sol in Codex. That's 280 runs, plus 56 targeted repeats where setups disagreed. The details are in the appendix.

Two parts of my story didn't survive even this round. MCP wasn't slower: every MCP setup ran at 0.71-1.06x the CLI's wall time. And the answers barely changed. Most setups solved every question or missed one. The two exceptions, curated gh verbs under Sonnet at 17 of 23 and Takt's shipped MCP at 9 of 12, come back below. The keys checked the answer, not the agent's report, because agents declare victory too early. The difference was the bill. I was ready to call it for CLIs.

The Control That Changed My Mind

There was one problem with my conclusion: I had changed two things at once. The protocol changed, but so did the operations available to the agent. GitHub's MCP server offers curated tools. The GraphQL CLI offers a query language.

So I set up a separate experiment where the operations can't change. Browserious, my remote-browser product, ships a CLI and an MCP server over the same operations, held together by a parity test. I gave both 27 browser QA tasks on a demo account, Sonnet only, one run each.

The penalty mostly vanished.

With the operations held fixed, MCP cost 1.13x the CLI, close enough that the transport stopped looking like the culprit. It even finished faster. Success didn't separate them either: every run that fell short, in both setups, was a partial on the same pointer-motion check.

These are different services and different tasks, so I can't subtract one ratio from the other, and one control with one model doesn't prove transports are equal everywhere. My reading is that interface design, not transport alone, explains much of the gap. My theory was half right. The cost was real. I'd blamed the wrong thing for it.

The transport did change one thing: secrets. In the MCP setup, the sign-in tasks could only pass the demo password literally, as an argument to page_fill, since there's no shell or environment expansion. The tool also echoed the value in its result. So the password went through the model's context and into the transcripts. CLI agents typed "$PW", and the value never appeared in the recorded transcript. That's the behavior of the setup I tested, not a law of MCP. If your MCP tools take secrets, resolve them by reference on the server, or authenticate before the agent starts.

Where the Cost Actually Comes From

The biggest differences weren't in the number of tools advertised to the model. They appeared after the tools started returning data.

Small tool lists are a design choice, not a protocol requirement. In a survey of 23 official CLI and MCP pairs, the gcloud MCP server had one tool and still reached every API family the survey sampled. GitHub's had 91 tools and reached 15 of 18. Claude Code also loads only tool names at the start now and fetches a schema when the agent needs it, so a long tool list isn't the bill it used to be.

The bill is what comes back.

When I saw the token breakdown, it was exactly the point I'd wanted to find. The shipped MCP's results dwarfed the GraphQL CLI's, and the expensive kinds of input, fresh input and cache writes, grew with them, about 8x for Sonnet on GitHub. Every call returns a full payload, and the conversation carries it into every request after it. The numbers support that mechanism. They don't isolate every cause, and a byte in a transcript isn't proof the byte reached the model.

Sol shows why that caveat matters. Its shipped-MCP runs on GitHub returned a median 789 KB, and one run returned 18 MB, yet used only 1.33x the tokens. My reading is that Codex truncated or spilled most of it before the model saw it. That's an inference, and if it's right, the runtime is quietly deciding what your agent gets to read.

Composability wins on the other side: the GraphQL CLI had the lowest cached input in all four service-and-model cells. One query that names the fields an answer needs beats a dozen calls that return everything.

I care beyond dollars. Context is capped: Sonnet 5.5 gets 1M tokens in Claude Code, and Codex compacts long conversations automatically, which blurs the first instructions. My view is that the noise and the compaction both make the model's intelligence degrade faster. That's my reasoning, not this experiment's finding. No run came near a cap or compacted, and these totals are input summed over requests, not the peak size of the window. I made the broader case in using Claude Code without technical debt: what enters the window shapes everything after it.

Composability Is Not Enough

The fourth setup, the one I called ridiculous, gave MCP a composable surface too: one graphql tool. It cut the cost in three of four cells, and on Takt with Sol it cost 0.96x the GraphQL CLI.

The surprise is GitHub with Sol. There the GraphQL MCP cost more than the shipped server, and it still made 5.79x the calls, because Sol fired many small queries instead of composing one.

A composable interface made efficient queries possible. It didn't make the agent compose them.

A thin surface also hides answers. My own MCP server returns Takt comments without dates, and three questions needed them. Sonnet failed all three, twice. Sol got one right once, by inferring dates from comment text and saying they "remain incompletely verified". That's a right answer nobody could check. I haven't acted on it, and I'm not sure I will. Takt's MCP payload is trimmed by design, and it can't answer some questions. C'est la vie. If you trim payloads the same way, write down which questions you're giving up.

Curated CLI verbs have the same edge. With gh verbs only, Sonnet failed all six GitHub questions built to need more than those verbs. Sol solved them with the same verbs, and nobody has read the transcripts for why.

And when the surface falls short, agents route around it. Three of 140 Sol runs broke the access rule, with Python HTTP or a git clone, and were thrown out. In a pilot, a Sol agent whose MCP server failed to start found the real browserious binary and did the task through the CLI. A Sonnet agent in the same spot stopped and reported.

Guessed past or routed around, both look like success until you check how the answer was made.

The Hidden Cost of Two Adapters

The tokens are one bill. Owning two adapters is another. In July, a guard against empty-string arguments went in at Takt's GraphQL boundary and never reached the MCP tools, because the MCP server imports the service layer directly. That bug class has bitten Takt eight times across six layers, once in the CLI itself. The guards went in door by door, then into one shared helper, and the last case into the shared service itself, so every transport rejects the input the same way. That's the rule I'd give anyone with two adapters: validate in the service both of them call, never at either door.

Permissions drift the same way. In one recovery, the MCP tool wouldn't release a stale claim without an admin token, while the CLI released it with the lease id.

Then compatibility. When Takt folded its status tools into one, the three old ones stayed as shims. With MCP, every rename is a shim I carry. GraphQL would also keep the old field, but it lets me mark that field deprecated in the schema, and MCP's Tool schema has no standard equivalent. I'd price that difference in before shipping an MCP server.

Choose the Surface, Then the Transport

The experiments changed the question I ask when building an agent integration. It's no longer "should this be a CLI or MCP?" First I ask what operations the agent needs. Only then do I ask how it should reach them.

The surface. Take one real question and see whether the agent can answer it efficiently with the operations it has. If not, fix composition before anything else. You don't need GraphQL for that. Wrapping an API that already composes is cheap, and if yours doesn't, find the call sequence one real task repeats and add an aggregate operation or field selection for it. An MCP server can take a query tool, or code mode, where the agent writes code that combines API calls and returns only the selected result, at the price of an execution sandbox and a permission boundary. Give the new tool the same token and scopes the curated tools already have, and return every field your answers need, dates included.

A one-tool MCP wrapping the API is a nominal MCP, just an adapter between API standards. It adds no capability. It adds reach.

These results surprised me, and I'm now considering a graphql tool for Takt's MCP. I think it's the most significant improvement I could make there, and it would probably let me drop some less popular tools. The other idea, MCP as a mode of the CLI, is still unshipped.

The transport. Agents with a shell get a CLI and an instructions file: when Maestro added a harness with no MCP at all, its agent still did a real Takt task end to end on taktcli alone. Clients that only speak MCP get an MCP adapter: a ChatGPT app, for one, is an MCP server. If you need both, build thin adapters over one shared service, the way Browserious ships both in one package, and test parity every release: an empty string, a null, an omitted field and one call that should be denied, through both doors.

Why I Still Run Both

When taktcli shipped, the plan was "coexist now, deprecate later". Four months on, Takt's MCP server is still mounted. I was ready to sunset it. Then someone asked me specifically for MCP credentials, because their agent environment only accepted pasted MCP settings, not a CLI setup script. A real consumer that only speaks MCP is the reason it stays, and the reason a query tool for it interests me.

"MCP is worse" was the wrong half of my theory. "Build it and you're done" was wrong too. Before you ship either adapter, run one check on your own surface:

1. Take one real question with a known answer.
2. Run your current surface and a composable alternative with the same model, runtime and credentials, in fresh sessions.
3. Record the calls, the bytes returned, and the fresh input, cached input and cost where the runtime reports them.
4. Check the answer, and check the agent used only the access you gave it.

Returned bytes are only a proxy for context, and one run is a first diagnostic, not a benchmark. The red flag is repeated fetches that one composed request would replace. If you see them, fix the surface first. Then ship the transport your clients can reach.