The token tax on tools you never call

Connect a Model Context Protocol server to an agent and something happens before the agent does any work. Most clients take every tool that server exposes and load its definition into the model's context: the name, a description, the JSON Schema describing its arguments. That payload sits in context, and you pay for it whether the agent calls the tool once or never.

We tend to read a tool list the way we read a menu at a restaurant. More options look like more capability, and at a restaurant the options really are free until you order. Here they are not. Each entry is resident text the model reads on the way to deciding anything, and the charge starts the moment it goes on the menu, before anyone orders.

Here is the shape of one definition, straight from the spec:

{
  "name": "get_weather",
  "description": "Get current weather information for a location",
  "inputSchema": {
    "type": "object",
    "properties": {
      "location": {
        "type": "string",
        "description": "City name or zip code"
      }
    },
    "required": ["location"]
  }
}

One tool is nothing. The problem is that the cost scales with the size of the catalog, not the size of the task. A job that needs two tools still carries the schemas for all of them. Anthropic reports a typical setup of five servers spending around 55,000 tokens on definitions before the agent does anything, and points out that most requests actually need three to five of those tools. Push the catalog toward thousands of tools and the agent processes hundreds of thousands of tokens before it even reads the request. Their most dramatic number comes from a different case, a workflow moving data from Google Drive into Salesforce that fell from 150,000 tokens to 2,000, but that one bundles two savings, loading fewer definitions and keeping the moved data out of context, so read it as the far end of the curve rather than a rate you can apply to your own tool list.

Tokens are only the visible half of the tax. The quieter half is selection quality. Every extra tool in context is one more thing the model has to hold apart from the others while it decides, and past roughly thirty to fifty tools its accuracy at picking the right one starts to fall. The definitions do not always help: aggregate a few servers and you hit the collision the spec calls out, two different servers each exposing a search tool, now needing a disambiguation prefix so the model does not reach for the wrong one. A bigger menu is also harder to order from.

A fair objection blunts one of those halves. The tool block renders at the front of the prompt, the most cacheable region there is, so after the first turn the agent re-reads it cheaply. True, but caching discounts the dollars, not the context window the definitions occupy and not the accuracy they cost. It refunds the re-read and leaves the two things that actually bite untouched.

This is where shelling out to a command-line tool starts to look less like a step backward. A CLI the agent invokes keeps its schema out of always-on context; the interface lives in a --help the agent reads only when it decides to use the thing. I lean on this in my own setup: for routine work against an internal dashboard, the agent calls one wrapped command rather than hand-assembling the raw API. The schema cost is not gone, though, it has moved. What stays resident is a pointer, a line somewhere telling the agent the command exists and when to reach for it, and the full argument list materializes only on the call. That is the whole trick, and yes, the --help is still tokens once the agent reads it.

The tempting lesson is "CLIs beat MCP servers," and it is the wrong one. The CLI does not win because it is a CLI. It wins because it defers the schema cost until the work reaches for the tool, and a server can defer the same way. Anthropic's own answer to the token problem does not abandon MCP; it changes when the definitions load, and the Claude API now ships this as a setting. Mark a tool defer_loading and it stays out of the prompt until a search tool surfaces it, at which point its schema arrives appended to the conversation. That last detail is the one that matters. On-demand loading has to append, because the tool block lives at the front of the prompt where the cache lives; delivering a discovered schema as a result leaves that cached prefix intact, while editing the registered tool set in place rewrites it and pays for the privilege. Defer by appending and you stop renting the whole building to use one room.

So the frame that survives is not a protocol war at all. The tool surface is a token budget, and you should price it like one. Every capability you leave switched on is context you carry into every decision the agent makes. Before you add the next tool, ask the question that actually predicts the cost: will the agent reach for this in the work in front of it, often enough to earn its place at the front of the prompt?

That question has a flip side the tax framing can hide: sometimes the resident tool is the right call. Anthropic's own rule of thumb keeps the handful of tools used on nearly every request loaded and defers the long tail, because a tool the agent reaches for constantly is cheaper resident, paid once and cached, than searched for every time. And some tools cannot be deferred at all. None of this is an argument against building servers, and I ship one. clipboard-mcp is a small Rust binary, and the reason it earns a permanent seat is not preference but shape: one of its three tools watches the clipboard for changes, which takes a live process bound to the session, something a one-shot shell-out cannot be. agent-recall, a memory library I maintain, makes the opposite kind of call, on the output side: a query returns a summarized briefing rather than the raw rows behind it, because the rows would land in context and sit there for the rest of the session. That cost lands per call rather than per turn, but it rewards the same care.

The number to watch is not how many tools your agent can see. It is whether the tokens it spends on definitions move when the job does. Change the task, and a surface priced correctly spends differently, because it is carrying what this task needs. A surface priced by the catalog spends the same every time, whatever the work, and that is the tax arriving in full: you are paying for tools you never call.