A round of benchmarks published earlier this month put a hard number on something we had been muttering about. Connecting an agent to a task through MCP costs roughly thirty-five times more tokens than calling the same operation through a CLI. Reliability on harder tasks drops with it, from close to a hundred percent down into the low seventies as protocol mediation accumulates. The example that made the numbers concrete for us: a CLI command and its help output runs about two hundred tokens, and the equivalent MCP server initialization for the same operation lands above ten thousand. Chain three connected MCP servers, and roughly a hundred and forty thousand of a two hundred thousand token context window is gone before any real work has happened.
The first reaction in our group chat was prompt tuning. The second, after a few hours of staring at traces, was that prompt tuning would not help. The overhead is structural. It is in the protocol choice, and it shows up the moment the agent boots.
That has changed how we think about wiring tools into agent workflows. Not “which protocol wins” as a question. More like rent. Every tool integration pays rent in tokens for as long as it is connected, and our job is to decide whether the integration is worth what it costs to keep around.
Where the overhead actually comes from
The thirty-five times figure is not a single number. It is the product of three smaller costs that show up at different points in a session.
The first is initialization. An MCP server hands the client a tool manifest, a list of capabilities, a set of schemas, often a resource catalog. The model reads all of it before it can act. A CLI has none of this. The model sees the command and its help text only when it needs them, and only the parts it asks for.
The second is per-call framing. Each MCP tool call carries a protocol envelope: the tool name, its arguments as a typed object, often a request id, often a session header, and the corresponding structured response. A shell call carries an argv array and produces text. The framing adds tokens both directions, and the cost is paid on every invocation, not amortized at the start.
The third is per-trace persistence. The tool manifest does not leave the context once it has arrived. It sits in the prompt for the rest of the trace. A long agent run with three connected servers is paying the full initialization cost on every turn, not just the first one. That is what produces the hundred and forty thousand token floor before work starts.
None of these are bugs. They are what gives the protocol its properties. Schemas mean the model does not have to guess about argument shape. Manifests mean tools can be discovered without prior knowledge. Sessions mean stateful tools can carry context across calls. The features are real. They are also what we are paying for.
When MCP earns its rent
We have ended up keeping MCP in three places.
The first is discovery across third-party surfaces we do not own. When we connect to a vendor system we did not write, and where the tool surface might change without warning, the manifest is doing work we would otherwise have to do by hand. Without it, the agent is guessing about argument shapes against an API it has never seen. The cost is high. The alternative, which is brittle hand-rolled wrappers that drift out of sync with the vendor, has been higher for us.
The second is auth-mediated tools shared across many agents. When several agents need to act through the same authenticated surface, putting it behind an MCP server gives us one place to handle token refresh, scope checks, and audit logging. The protocol overhead is the price of not duplicating that logic into every agent that needs the surface. We have tried the duplicated version. It was cheaper in tokens and much more expensive in incidents.
The third is non-deterministic environments where structured outputs prevent parsing disasters. If the underlying tool returns something the model has to interpret, and the interpretation has a real chance of going wrong, the typed response from an MCP server saves us from a class of failure we cannot afford. The overhead buys correctness on the part of the trace that is most likely to break.
What these three have in common is that the cost is paid in service of a property the agent could not get any other way. We are not buying convenience. We are buying something structural.
When we drop back to CLI
For everything else, we have moved to CLI. Internal tooling we own and can introspect directly. Deterministic operations where the output shape is known and stable. Tight loops where the same operation runs hundreds of times in a trace and every token saved compounds.
The pattern that surprised us most was the tight loop case. We had assumed that the per-call framing of MCP was small enough not to matter once the manifest was already in context. In a trace that calls the same tool four hundred times, the framing cost on each call adds up to more than the initial manifest. CLI calls in the same loop barely show on the trace at all.
The other thing we found is that “internal” is doing a lot of work in the rule above. A tool we built ourselves, in a repository we control, with a help text we wrote, is something the model can read once and call confidently for the rest of the session. The discoverability that the manifest buys is wasted on a tool the agent already has full information about.
The rule we write down at design time
The rule we have ended up with is short. When a tool is first introduced into the system, we pick the protocol then, not after the context window has started filling up. The protocol choice is recorded next to the tool. If the answer is MCP, we write down which of the three reasons it qualifies under. If the answer is CLI, we write down what we are giving up by skipping the manifest.
This is the kind of decision that is cheap to make early and expensive to revisit later. By the time a tool is in production, changing its protocol layer means touching every caller, re-testing every trace, and re-validating every authorization surface that depends on the old shape. We have done that migration once. We would prefer not to do it twice.
The number that started this is a forcing function, not a verdict. Thirty-five times more tokens is what we pay when we let the protocol decision drift into a default. It is also, in the places where the protocol is doing real work, what we have decided is worth paying. The discipline is being able to tell the difference, and writing the difference down before anyone has to argue about it in a postmortem.