People budget for conversation tokens and forget the ones that are always there: the system prompt, the tool schemas, and the resource descriptions. They are re-sent on every turn, and they are not compressible by asking nicely.
A tool definition is roughly a name, a description, a JSON schema, and sometimes examples. Small ones run to a couple hundred tokens; a server exposing twenty tools with detailed schemas can pass several thousand on its own. Connect five of those and you have spent a real fraction of a 32K window before the first message.
Why this bites harder than it looks
Three reasons. First, it is charged on every request, so the multiplier is your conversation length, not your message length. Second, it competes with the actual work: a long document and a large toolset cannot both fit. Third, it changes behavior — too many overlapping tools make the model choose worse, not better.
The practical test
List your connected servers and ask, for each one, whether you used it in the last week. Most people find two or three that were installed for a demo and never removed. Disconnect them. This is the highest-return change available and it takes a minute.
Measure before you optimize
Paste a representative prompt into the context budget checker and see where you land. If you are under 30% of the window, stop reading. If you are over 70% before the conversation gets interesting, the toolset is the first suspect, not the model.
What good looks like
Narrow servers beat broad ones. Filesystem with one root is cheaper and safer than a kitchen-sink server with twelve capabilities. And if a server keeps getting ignored, that is data: remove it and watch whether anything breaks.
The cost of a tool you do not use is not zero. It is paid on every request, forever, in money and in attention.