Your MCP Server Is Charging You 7,000 Tokens Before You Ask It Anything

When an MCP client connects to a server, it asks for the tool list. The server replies with every tool it has, each one described in full, with a complete JSON schema for its arguments. All of that lands in the model's context window before you type anything.

We had never measured ours. When we did, the number was 36 tools and roughly 7,000 tokens.

That is a strange bill for DeerDawn to hand you, given that the entire product is about protecting your context window.

The cost is charged every session

This is not a one-time setup cost. The tool list is sent on every connection, which means every session, forever. If you work across three tools, you pay it three times. It is the single largest fixed cost an MCP server imposes, and it is almost never measured because it never appears in a latency graph or an error log.

Token cost is only half of it. A model choosing between 36 tools makes worse choices than one choosing between 14, and DeerDawn had nine tools that all meant roughly "help me orient in this project." Near-synonyms are hard to pick between, and the model pays for the deliberation whether or not it picks correctly.

The fix is not deleting tools

The obvious move is to delete the tools nobody uses. We could not, and the reason is worth explaining, because it applies to any MCP server that has shipped.

DeerDawn writes instruction blocks into files on your disk: CLAUDE.md, AGENTS.md, .cursorrules. Those files name tools as literal strings. So do the hook commands in your settings. Every one of those names is a published contract sitting on machines we do not control, and MCP has no alias or redirect mechanism. Rename a tool and you break every install that already has the old name written down.

So we separated two things that had always been the same thing: which tools we ADVERTISE, and which tools we can CALL. Every one of the 36 names still works. We just stopped listing them all.

Advertise what the session might need

The list is now driven by state rather than by inventory.

Setup and authentication tools appear only while you are signed out. Once you are signed in they are dead weight, because setup is something that happens once, not something a session does. Bootstrap tools, the ones for creating and importing a project, appear only until this workspace has a project bound. Skills tools appear only if you actually have skills. The core loop, the twelve or so tools a working session genuinely uses, is always there.

The server declares its tool list as dynamic, so when authentication resolves mid-session it tells the client to re-read the list and the surface narrows on the spot.

Steady state went from 36 tools and about 7,000 tokens to 14 tools and about 3,553. Roughly half, given back to you on every session.

Fail toward showing too much

There is a timing problem worth naming. The tool list is requested immediately after the connection opens, sometimes before we know whether you are signed in or which project you are in.

When we do not know, we send everything.

Hiding a tool the session needed produces a broken session with a confusing failure. Sending a list that is briefly too large produces the situation we were already in. Those are not symmetric, so the default is not the elegant one, it is the safe one.

What we measured, and what we did not

The 49% cut is real and it is guarded by a test that fails the build if the payload grows past budget. But the count was the easy half. The remaining 3,553 tokens are mostly long descriptions and wide argument schemas on a small number of tools, and trimming those is the next piece of work.

If you run an MCP server, the useful exercise takes five minutes: connect to it, capture the tools/list response, and divide the byte count by four. Whatever that number is, your users pay it every session.