mcpagentsrouting

MCP Routing With 3+ Servers

Once you have 3+ MCP servers, routing becomes a description-writing problem. Patterns for precise tool descriptions.

5 min read

Once an agent has more than two MCP servers connected, every tool-using turn becomes a routing problem. An r/opencodeCLI thread surfaced the symptoms: 35 npm processes, 50K-token schema loads, and agents that called the wrong tool half the time. The first fix is a gateway. The second fix is rewriting tool descriptions so the model picks correctly.

Routing is a description problem

The model picks tools based on tool descriptions. If two MCP servers both expose a "search" tool with similar descriptions, the model picks one randomly. That looks like a routing failure but it's actually an ambiguity in the descriptions.

The standard 2026 fleet

A typical multi-agent setup has: Postgres MCP for schema lookups, GitHub MCP for code, Linear MCP for tickets, Scavio MCP for web search, plus 2-3 internal MCPs for org-specific data. Each server's tool descriptions need to make clear which queries they should and shouldn't handle.

Writing precise tool descriptions

Compare these two descriptions for the same tool. Bad: " Search the web." Good: "Search Google SERP for fresh web pages, news, AI Overview citations. Use this when the user asks about current events, products, recent releases, or topics that change daily. Returns up to 10 typed results with title/snippet/link."

The negative cases matter most

Bad descriptions miss when the tool should not be called. Good descriptions include lines like "Do not use this for questions about the user's codebase or internal docs — use the GitHub MCP or Confluence MCP for those." The negative cases prevent crossover failures.

Text
Scavio MCP search tool description:
"Search the open web for fresh content. Use for: current events,
product launches, news, public information, AI search visibility
checks, competitor research. Returns up to 10 typed JSON results.
Do NOT use for: internal company data (use Confluence/GitHub MCPs),
schema queries (use Postgres MCP), or ticket lookups (use Linear MCP)."

Routing gets harder with overlap

Two search-shaped MCPs (Tavily MCP plus a Reddit MCP plus a YouTube MCP) compete for the same kind of query. The model struggles. Replacing 3-4 search-shaped MCPs with one Scavio MCP eliminates the overlap and makes routing trivial — there's only one search tool, with multi-platform parameters baked in.

The MCP gateway architecture

For non-search MCPs, run a gateway that proxies upstream servers. Each agent connects to a single endpoint. The gateway can compress tool descriptions, filter by current task, or even drop schemas entirely until a tool gets called (lazy schema loading is increasingly available in 2026).

Measuring routing quality

Log every tool call from the agent. Tag each as correct/incorrect/missed. Compute the percentage that picked the right MCP for the query. Aim for above 90%. Below 70% means the descriptions are unclear; rewrite them.

Cost discipline

Per-turn schema cost on a 5-MCP setup with verbose descriptions: ~30K tokens. Same setup with tight descriptions and a gateway: ~5K tokens. On a 30-turn session, that's the difference between $0.30 and $0.05 of pure overhead. Multiplied across users, the gap is real.

What this looks like in practice

A Claude Code agent with 5 MCPs attached. The user asks "what are the latest AI Overview citations for our brand?". Without precise descriptions, the model might call the GitHub MCP's search tool. With precise descriptions, it routes correctly to Scavio MCP's search-with-ai-overview tool on the first try. The user sees a better answer 5-15 seconds faster.

The single biggest lever

Once a stack has 3+ MCP servers, the discipline of writing precise tool descriptions becomes the biggest lever on agent quality. More important than picking the latest model. More important than fine-tuning prompts. The model is only as good as the routing decisions you set up for it.