40 tools on one mcp server or split into five, schemas eat 11k tokens tool-schema

Split, but not into five servers - into task-shaped tool sets, which is a different axis. Servers are a deployment detail; what the model sees is one flat list, and it does not care which process a tool came from.

What worked for us at a similar size:

• a small router step that picks a tool set from the user's request before the main loop starts. One cheap call, one enum output, no tools attached. It picks deploys or warehouse and the main loop gets 8 tools instead of 40.
• a load_tools(domain) escape hatch for the 5% of requests that cross domains, so the router being wrong is recoverable rather than fatal.
• ruthless deduplication first. Of your 40, I would bet 12 are variations that could be one tool with an enum parameter. restart_service, restart_worker and restart_all are one tool.

You have already found the thing that matters, which is that the accuracy curve turns before the cost curve does. Caching makes 40 tools affordable and does nothing about the model reading 40 similar descriptions and picking the fourth-best one.

You need an eval set before you change anything, or you are going to be arguing about vibes for a month. Take 80 real requests from your logs, label the tool that should have been called first, and run the whole set on any candidate configuration. It is an afternoon of work and it turns "accuracy has clearly got worse" into a number that either moves or does not.

We found the biggest single win was not the count at all - it was rewriting descriptions so each one said when not to use the tool. Nine of ours started with almost the same sentence.

Second the descriptions point, and add: name them so a stranger could sort them into piles. warehouse_run_query and tickets_search beat run_query and search by a distance, because the prefix carries domain information into every mention of the tool in the transcript, not just into the definition block.

Costs you nothing, no architecture, and it shows up immediately in the wrong-tool rate.

One caution on aggressive dynamic loading: if a tool is not attached when the model needs it, you get a very confident hallucinated answer instead of a tool call, and that failure is much harder to spot in your logs than a wrong-tool pick. Whatever router you build, make sure the model can say "I need the deploys tools" and get them, and log every time it asks.

Also worth asking which of the 40 an ops person has ever actually needed the agent for. We audited a year of runs and 6 tools covered 84% of successful sessions. The tail was not adding capability, it was adding candidates.

The 11,400 number is worth breaking down before you optimise it. Ours was 9k and about 3.5k of that was two tools with enormous nested parameter objects for filters nobody used. Trimmed those two schemas to the four fields that get set in practice and the whole budget dropped by a third without removing a single tool.