← Back to Blog
July 29, 2026 · 5 min read

The Context Tax: What Every Connected Tool Costs Your Agent

The context tax is the fixed token cost your agent pays for every connected tool, on every single turn, whether the tool gets used or not. Connect an MCP server and its tool schemas (names, descriptions, JSON parameter definitions) load into the model's context so it knows what it can call. That load repeats each turn. It is a tax in the precise sense: charged up front, charged always, and unrelated to usage.

The phrase has been floating around the MCP world through 2026, usually as a complaint. Let's define it properly, measure it, and rank the fixes.

How the tax works, mechanically

A language model can only call tools it can see. So before your prompt is read, the client sends along the definitions of every available tool. One well-documented tool with a few parameters lands somewhere between 200 and 500 tokens; 350 is a fair working average.

Nobody connects one tool. A typical server ships 10 to 30, and a working setup connects several servers. That is where the multiplication bites:

SetupToolsTax per turn (at 350 tokens)
1 small server103,500 tokens
4 servers6021,000 tokens
10 servers15052,500 tokens

Now the part that makes it a tax rather than a fee: agents loop. A 25-turn session with 150 connected tools pays 52,500 tokens of schema on every one of those turns. That is over 1.3 million input tokens per session spent on descriptions of tools, most of which were never called. The task might have needed eight of them.

Prompt caching discounts the repetition where available, and you should use it. But cached schemas still occupy the context window (52,500 tokens is a quarter of a 200k window, gone before work starts), and the cache resets whenever your tool list changes. The tax gets cheaper. It does not go away.

The second cost: choice degradation

The token bill is the visible half. The invisible half is what a 150-tool menu does to decision quality. Every server brings its own search, its own list, its own get. The model now picks from a crowd of near-duplicates, and wrong-tool calls and hesitation loops rise with catalog size. Each wrong call is a full turn of context, paid, plus a retry. The tax compounds itself.

Measure your own tax in five minutes

No benchmark needed, just your own setup. Start a session, make one trivial request, and look at the input token count for that first turn. Subtract your system prompt and your message. What remains is, almost entirely, your context tax. Then ask the only question that matters: how does it compare to the tokens your actual work consumed? If the menu costs more than the meal, you are the customer restaurants dream about.

The three fixes, ranked

Fix 1: prune per project. The cheapest fix and the least satisfying: connect only the servers a project needs, disable the rest. Works immediately, costs reach. You will predict wrong about what tomorrow's task needs, and you will maintain those per-project lists forever. Our post on [how many MCP servers is too many](/blog/how-many-mcp-servers-is-too-many) covers where the practical ceiling sits.

Fix 2: trim what loads. Some clients let you disable individual tools; some servers offer slim profiles; shortening verbose descriptions helps at the margin. Real savings, real fiddling. The wider set of tactics lives in [how to reduce MCP token usage](/blog/reduce-mcp-token-usage).

Fix 3: federate behind a gateway. The structural fix. An [MCP gateway](/blog/what-is-an-mcp-gateway) merges your servers behind one endpoint, which means one place decides what the agent's catalog looks like. Instead of every server dumping its full menu on every turn, tools can be exposed as tasks need them. Adding an eleventh server stops meaning an eleventh permanent catalog in context. This is the approach we build at Tulimoa (gateway in early beta, not self-serve yet), and it pairs with the other structural saving: a memory layer, so recalled context replaces re-fetched context. That second lever is its own topic: [where your LLM token bill actually comes from](/blog/where-your-llm-token-bill-comes-from) breaks down both.

The honest ranking: do fix 1 today, fix 2 where it is easy, and treat fix 3 as the way to stop doing fixes 1 and 2 by hand forever.

Frequently asked questions

What is the context tax in one sentence?

It is the standing token cost of tool definitions that every connected MCP server loads into your agent's context on every turn, independent of whether those tools are used.

Does the context tax apply even when my agent calls no tools?

Yes. Schemas load so the model knows its options; the load happens before any decision to call. A session that never touches a tool still pays the full tax on every turn.

Is the context tax an argument against MCP?

No, it is an argument against naive MCP topology. The protocol is what makes tools portable at all. The tax comes from connecting everything everywhere all the time, and it has fixes, from per-project pruning to gateway-level federation.