Your MCP server is eating the context window

The fastest way to wreck an agent is to hand it a sloppy MCP server. I found this out the dull way, watching a capable model go vague and start fumbling steps it had nailed an hour earlier. When I actually looked at the prompt, it was two thirds full before the agent had done a single useful thing. None of that space went to the task. It went to tool definitions and tool output. If you are connecting an agent to tools right now, the MCP server context window problem is the one that bites first, and the docs barely mention it.

I have been plugging LLM features and small agents into real products for a while, and the same lesson keeps showing up in a new costume. The model is rarely the bottleneck. What you put in front of it is.

Where the tokens actually go

An MCP server spends your context in two places, and both hide until you measure them.

• Schema cost. Every tool the server exposes ships its full definition into the prompt: the name, the description, each parameter, every nested type. Connect three talkative servers and you can burn a few thousand tokens before the agent reads its first real instruction.
• Result cost. A single call can return a wall of JSON. A schema introspection tool on a database with two hundred tables. A directory listing with every file attribute. A search that hands back forty hits with all fields on each one. The agent needed three numbers and you gave it a phone book.

Both of these feed straight into the slow decay I wrote about in context rot. The window does not have to be full for quality to drop. It just has to be cluttered, and a chatty MCP server is a clutter machine running on autopilot.

A tool schema is an API you publish to a model

The mistake I see most is treating tool definitions as throwaway config. They are not. A tool schema is an interface, and it gets read by the model on every single call, so I design it the same way I design a public API meant to last. Small surface, clear names, no surprises.

In practice that means a few habits.

• Expose the tools the job needs, not the whole catalog. If six tools cover the work, do not register thirty. Every extra one is permanent rent on the context.
• Write descriptions that are short and exact. The model uses them to pick a tool. A vague paragraph makes it guess, and a wrong guess costs you a whole round trip of tokens and latency.
• Keep parameters honest. Mark optional things optional. Do not dump a sixty value enum into the schema when a free text field and one good sentence would do.

None of this is exotic. It is the boring discipline of API design, pointed at a new kind of client that happens to read your schema every time it thinks.

Trim what the tools hand back

The default get_everything tool is the quiet villain here. It feels generous and it is poison for context. When I built the query layer behind ElasticSwap, the whole game was returning a tight slice of on-chain data instead of the entire dataset, because the difference was a fast product versus a frozen one. The same instinct applies to MCP tools, just with the model as the consumer instead of a frontend.

So I cap and shape results at the server, not after they have already landed in the prompt.

• Paginate by default and return a count, so the agent can ask for more only if it needs it.
• Return the fields that matter for the task, not the full record. A row with three useful columns should not arrive with thirty.
• Summarize on the server when you can. A tool that says what it found in a sentence often beats one that dumps raw rows the model then has to wade through.

A tool that returns less is not a weaker tool. It is one that respects the budget it is spending on your behalf.

Spend the context like money

I have stopped thinking about context as a container to fill and started treating it as a budget I am spending every call. That framing changes which MCP server I trust. The good ones let me control verbosity, filter fields, and page through results. The bad ones assume infinite room and make me pay for it on every turn.

There is a real bill attached too. Each token of schema and stale result rides along on every subsequent call for the rest of the run, which is exactly the kind of slow leak I watch for when I am keeping LLM costs from wrecking a margin. Tight tooling and a sane invoice turn out to be the same piece of work.

The cheap test before you blame the model

Before you reach for a bigger window or a smarter model, measure where your context goes. Log the token count at each step and split it three ways: tool schemas, tool results, and the actual task. The first time I did this on a misbehaving agent, the task was a thin sliver and two fat servers were eating the rest. I cut the tool list, capped the results, and the same model that looked dim suddenly looked sharp.

Most agent failures I get pulled in to fix are not a weak model. They are a model buried under tooling nobody bothered to trim. Keep the schemas small, keep the results lean, and treat every MCP server as something that has to earn the room it takes. I keep more notes like this in my AI writing, and the rest of the work is on the homepage.