Token-Efficient MCP Tool Use

What is token-efficient MCP tool use?

Token-efficient MCP tool use means you only pay tokens for a tool's schema when the agent actually calls it, and you compact what the tool hands back before it lands in context — instead of pre-loading every server's full manifest on every turn and pasting raw output verbatim. The default behaviour of most agents is the opposite of efficient: connect an MCP server and its entire tool list rides along with every message, then whatever a tool returns gets dumped into the context window unfiltered. Both of those are fixed taxes you can mostly stop paying. I build token tooling for a living, and MCP is where I see the most waste per unit of effort to fix. The protocol is great — it's the cleanest way I've found to give an agent real capabilities. But the way it's wired up by default treats tokens as free, and they are emphatically not free. This piece is the practitioner's version of the fix: what to do at the schema layer, what to do at the output layer, and where a tool can just handle it so you don't have to think about it. This is a spoke off the broader question of how to reduce AI coding agent token usage. If you want the whole menu of levers, start there. Here I'm staying narrow on MCP.

Why do MCP tools cost more tokens than you think?

MCP tools cost more than you think because you pay twice: once for the schema on the way in, and again for the output on the way out — and both happen on a per-turn basis you rarely watch. A coding session isn't one request; it's dozens or hundreds of round-trips. Every round-trip re-sends the system prompt plus the tool manifest of every connected server, and every tool call appends its raw result to the running transcript. The schema side is the part people underestimate. A big server ships a lot of tools, and each tool carries a name, a description, and a full parameter schema. Connect two or three heavyweight servers and you've spent a meaningful slice of your window on text the model ignores most of the time. With Claude Opus 4.8 at $5 per million input tokens, a fat manifest is cents per turn — trivial once, painful across 150 turns in a session. Prompt caching helps here, since cache reads run at roughly 10% of the input price, but caching is a discount on a bill you can often avoid entirely: a manifest you never call is tokens you never needed to send, cached or not. The output side is sneakier. Tools love to return JSON — and JSON is verbose, repetitive, and full of fields the agent will never read. A "list files" call can hand back a few thousand tokens of metadata so the model can use one path. A web fetch returns the whole DOM when the agent wanted one heading. None of that is wrong, exactly; it's just unfiltered, and unfiltered is expensive. On Sonnet 5 ($2 / $10 per MTok) or Haiku 4.5 ($1 / $5) the absolute numbers shrink, and on GPT-5.5 ($5 / $30) the output side bites harder because output is priced at a premium — but the ratio holds across all of them: you're paying continuously for bytes the model doesn't use. The numbers behind this are collected in our AI coding agent token costs breakdown, and the per-model rates in our LLM API token pricing reference.

How do you cut the schema cost?

You cut the schema cost by loading tool manifests lazily — sending a thin index up front and resolving a tool's full schema only when the agent reaches for it. This is the single highest-leverage move on the input side, and it's worth its own treatment: see lazy MCP loading for the mechanics. The short version is that the per-turn floor — the tokens you pay before you've said anything useful — collapses toward zero for servers you aren't currently using, while you keep every capability. If you'd rather not wait for a layer to do it, you can get most of the benefit by hand today:

Audit what's connected. List your active servers and ask, honestly, for each: do I call this most sessions, or once a week? The manifest cost is paid daily regardless.
Prune ruthlessly. The cheapest token is the one you never send. A server you touch weekly is usually better connected on demand than left on permanently.
Keep one or two always-on. Pick the servers that fire on most turns; treat the rest as lazy candidates. Our best MCP servers for Claude Code ranking scores common servers on exactly this — token cost, not just usefulness.

This is the same family of move as the rest of context engineering: decide what earns a place in the window before the model ever sees it, rather than after.

How do you cut the output cost?

You cut the output cost with output filtering — compacting a tool's result down to the bytes the agent will actually use before that result enters context. The principle is the same as the schema side, applied to the return trip: most of what a tool emits is structure, repetition, and fields nobody reads, and you can fold that away without losing the signal. In practice this means a few things stacked together:

Drop the boilerplate. Pagination wrappers, timestamps, ETags, repeated keys across array elements — none of that helps the model reason. Context compression trims it.
Deduplicate. Tool output is full of near-identical rows. Collapsing them to a representative plus a count keeps the meaning at a fraction of the tokens.
Summarise the long tail. When a fetch returns a 40 KB document and the agent wanted one section, returning the section plus a one-line map of the rest beats returning the whole thing.

For codebase work specifically, the biggest output win is upstream of all this: don't dump whole files at all. Use semantic code search to retrieve the few functions that match the intent — backed by embeddings over the repo, the same RAG idea everyone uses for docs — instead of reading entire files into context so the model can ignore 90% of them. A "read file" tool is a token firehose; a "find the code that does X" tool is a teaspoon.

How to apply token-efficient MCP today

You can get from "leaking tokens" to "paying for what you use" in an afternoon, roughly in order of effort:

Measure first. Run a normal session and look at how many input tokens land before your first real instruction, and how big your average tool result is. Eyeballing isn't measuring. Our measure agent token usage walk-through covers this, and you can sanity-check rough figures with the token counter and the LLM token cost calculator.
Prune and lazy-load the schema side. Disconnect the servers you use occasionally; keep the one or two that fire constantly. That's manual lazy loading, and it's free.
Filter the output side. Where you control a tool, return the minimum useful shape. Where you don't, put a compacting layer in front of it.
Let a layer do it automatically. Manual discipline is real work and you'll get it wrong on a busy day. This is where Tokenade comes in: it sits between your agent and its MCP servers and loads manifests lazily — full schema fetched only when the agent reaches for a tool — so a four- or five-server setup costs roughly what one server did. It compacts noisy tool output before it hits context, swaps whole-file reads for semantic search, and shows the savings on a dashboard so you can watch the per-turn floor actually drop. It works the same way across Claude Code, Cursor, Codex, Copilot, and Windsurf, the free tier covers about 10M tokens a month, and Pro is $24.90/mo (excl. tax, US) with unlimited machines. It's source-available under MIT, so you can read exactly what it does to your traffic before you trust it with any.

If you only do one thing from this list, measure — because the savings on both the schema and output sides are large enough that you'll feel slightly annoyed you weren't tracking them sooner.

What goes wrong (anti-patterns)

The failure modes here mostly come from confusing "connected" with "free" and "returned" with "needed." A few to watch for:

Hoarding servers. Connecting every interesting MCP server "just in case" is the most expensive habit on the schema side. Each adds fixed per-turn overhead whether it fires or not. If you wouldn't pay a monthly fee for a tool you use once a fortnight, don't pay a per-turn tax for it either.
Trusting raw output. Letting tools dump unfiltered JSON into context is the most expensive habit on the output side. The model reads a fraction of it and you pay for all of it. Compact before context, not after.
Filtering too hard. Over-aggressive output trimming can drop the one field the agent actually needed and cause a re-call — which costs more than the bytes you saved. Filter the boilerplate and the long tail; keep the signal.
Lazy-loading the wrong tools. Deferring a tool that fires on most turns just adds a round-trip to resolve its schema every time. Lazy loading is for the long tail, not the one or two servers you live in.
Assuming caching makes it free. Prompt caching cuts re-send cost to roughly 10% of input, which is excellent — but it's cold on the first turn, breaks when a manifest changes, and never beats not sending the bytes at all. It's a discount, not an exemption. (If you keep hitting limits anyway, that's usually a rate-limit problem, and fewer tokens helps there too.)

The honest summary: most of us connected too many MCP servers, never counted what their manifests cost, and let the tools fire-hose raw output into context because it was the path of least resistance. Token-efficient MCP is two structural fixes — pay for schemas when you call them, compact output before it lands — and unlike a lot of context engineering, both are things a tool can just do for you while you get on with shipping.

See also:

How to reduce AI coding agent token usage
Lazy MCP loading
Best MCP servers for Claude Code
Claude Code MCP: how to set it up
Tool calling (function calling) — the primitive every MCP server is built on
MCP — glossary
Output filtering — glossary