MCP tool schemas are quietly eating my context budget.

Discussion

I connected 4 MCP servers to one agent and noticed tool-selection accuracy dropping as I added more, and It wasn't random either, the decline was surprisingly consistent and almost tracked linearly with server count, so i started counting tokens.

Every tool an MCP server exposes gets serialized into the request. That includes the tool name, description, and the entire JSON Schema for its inputs including descriptions for every property. All of that gets sent on every turn, not just the first one.

With 4 servers I ended up with around 60 tools. Just the serialized tool definitions were taking roughly 11–12k tokens before the model even saw my system prompt, which itself was under 2k.

The token cost was annoying, but that wasn't even the biggest issue.

The model has to attend over all those tool definitions every time it decides which tool to call. Most of my schemas had long auto-generated descriptions full of generic boilerplate along with exhaustive property descriptions. The information that actually differentiates one tool from another was getting buried under a lot of repetitive, low-information text.

What ended up helping wasn't reducing the number of tools, it was reducing the number of tools the model could actually see.

Instead of exposing every server's entire toolset upfront, I only expose a lightweight search and loader step. The agent first figures out which tools it needs, then loads those 3 to 5 tools into context while everything else stays out.

That brought the serialized tool block down to around 2k tokens on a typical turn. Routing accuracy improved, latency dropped, and token usage came down simply because there was much less context to process.

The thing I completely underestimated was that the important variable isn't really the number of tools, It's the amount of serialized schema sitting in the active context.

I'd much rather have 10 tools with concise schemas than 4 tools where every description runs for three paragraphs. Even trimming the description fields in my own MCP server gave a bigger improvement than I expected for such a small change.

What's everyone else's approach here? I'm currently using search then load, which has worked well so far, are you dynamically loading tools, aggressively trimming schemas, putting everything behind one large server, or doing something completely different?

Posted Jul 11, 2026, 8:49 PM UTC

416
Loading comments…