The hidden token tax in every MCP call

Every MCP tool call returns far more than the model needs, and you pay input-token cost for all of it. The hidden token tax is the gap between what a tool returns and what the model actually uses. You cut it by trimming responses to the fields that matter before they reach the context window.

MCP, the Model Context Protocol, is how AI agents call tools. It is a good standard, and the tax is not really its fault. It comes from connecting software built for software to a model that pays by the token.

Where the tokens actually go

There are two places. The first is tool definitions: the schemas and descriptions for every connected tool, loaded into context so the model knows what it can call. The second is tool responses: the data each call returns, dropped into the context window in full.

Both are charged as input tokens on every request. The model pays to read them whether or not it uses a single field.

The schema tax is being solved

Loading every tool definition upfront was the first visible cost, and it was large. A stack of connected servers could spend tens of thousands of tokens describing tools the model never called. Anthropic and others have written about cutting this, for example by letting agents load definitions on demand and call tools through code rather than loading everything at once.

Deferred or lazy tool loading genuinely helps here. If your only token problem was schemas, much of it is already closing.

The output tax is the one nobody owns

The larger, quieter cost is the responses themselves. Tools were built for software, so they return everything: every field, every nested object, full pagination, timestamps, internal IDs. The model needed two values and was handed two hundred.

This is the tax that lazy loading does not touch, because it happens after the model has chosen the tool. The call runs, the full payload comes back, and you pay for all of it on the way in.

A worked example

Take a single list_campaigns call against a typical SaaS tool. The raw response carries 52 fields per record: sending schedules, sequence variants, two dozen stats counters, tracking flags, pagination. The model was asked one thing and needed maybe two of those fields, the id and the name.

Trimmed to those fields, that one response goes from 20,894 tokens to 370. That is around 98 percent fewer, on that call. The model gets a cleaner input and a better chance of using it, and you stop paying for 50 fields of noise.

That 98 percent is the fattest case, not the average. It is what a heavy list or read endpoint looks like, and those are common, but they are not everything. The same pattern shows up on live traffic through the Connor gateway: one apollo_organizations_enrich call went from 8,801 tokens to 1,853 once distilled — 79 percent fewer, on that call and every call like it after.

What it looks like across a team

Across a real mix of calls, plenty are already small, so the blended saving is lower. In one example month, a team of heavy AI users made 100,000 tool calls. Trimming responses took the tokens delivered to the model from 250 million down to 165 million: 85 million saved, about a third of the total.

A third sounds modest next to 98 percent, and it is the honest number. It is also a direct, recurring cut to a bill that only grows as more people use AI. The 98 percent is real on the calls that matter most; the third is what it averages to once you count the cheap calls too.

When the token tax is worth fixing

It is worth fixing once AI spend is a number someone asks about, and once your agents lean on list and read calls against real tools. Below that, the waste is real but small. Above it, you are paying every day for fields no model ever reads.

Trimming tool responses to the fields that matter, before they reach the model, is what Connor calls Distill. It is invisible to the person using the tool, and it is the part of the bill you can cut without changing how anyone works.