Enterprises rarely stop at one Model Context Protocol server. The ticketing system, the wiki, the CRM, and the data warehouse each publish their own tools, and the agent that is actually useful can reach all of them. This article covers what the official documentation says about composing servers, and where you should add routing logic of your own.
The hard limits and the soft ones
On Managed Agents, an agent supports a maximum of 20 MCP servers, and server names must be unique — the name is how an mcp_toolset entry in tools grants access to a server, so the unique-name rule is also your collision guard: two servers that both call themselves search cannot coexist on one agent. Assign names that encode the system (jira, confluence, salesforce) rather than the capability, and collisions disappear by construction.
The soft limits bite earlier. Anthropic's own documentation notes that a typical multi-server setup can consume around 55,000 tokens in tool definitions before the conversation even starts, and that Claude's tool-selection accuracy degrades once more than 30–50 tools are loaded into context. Five servers with fifteen tools each puts you past both thresholds.
Tool search: load definitions on demand
The documented fix is the server-side tool search tool. You mark most tools with defer_loading: true; their full definitions are still sent in tools on every request, but they stay out of Claude's context window until Claude searches for them. Searches match names, descriptions, and argument descriptions, return up to 5 tools by default, and the API expands the matches automatically. Two variants exist: a regex flavor (tool_search_tool_regex_20251119) where Claude writes Python re.search() patterns, and a BM25 flavor for natural-language queries. According to the docs, deferred loading typically cuts definition token usage by over 85%, and up to 10,000 deferred tools are allowed per request — far beyond any realistic server fleet.
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="acme-ai", region="global")
tools = [{"type": "tool_search_tool_bm25_20251119", "name": "tool_search"}]
for t in enterprise_tools: # your MCP-derived definitions
tools.append({**t, "defer_loading": True})
resp = client.messages.create(
model="claude-opus-4-8", max_tokens=2048,
tools=tools,
messages=[{"role": "user", "content": "File a Jira bug for order 8812"}],
)Guardrails from the docs: at least one tool must stay non-deferred (normally the search tool itself — deferring everything returns a 400), a deferred tool cannot also carry cache_control, and discovered definitions are appended after the cached prefix, so tool search plays nicely with prompt caching. Loaded definitions bill as ordinary input tokens; the search itself is not metered as a separate server tool.
Routing by capability
Tool search handles discovery within a request. Above it, we recommend an application-level routing layer that decides which servers a given workload sees at all:
Per-agent rosters. Rather than one mega-agent with 20 servers, define several Managed Agents — a support agent with ticketing and CRM servers, an engineering agent with repo and CI servers — each with only the toolsets and vault credentials its job needs. This is least privilege as architecture, and it keeps every agent under the accuracy threshold.
Per-session overrides. Managed Agents supports session-scoped tool and MCP-server overrides on an existing agent, so a router can narrow (or swap) the server list for a single session without minting a new agent version.
A gateway in front. Some teams aggregate several internal MCP servers behind one façade server that enforces naming conventions and access rules centrally. That is a recommended practice rather than a platform feature — evaluate it like any other piece of middleware you would own.
Platform availability
Check both features against your platform. The MCP connector on the Messages API is beta on the first-party Claude API, Claude Platform on AWS, and Microsoft Foundry — and not available on Amazon Bedrock or Google Vertex AI (there, your application talks to the MCP servers itself and forwards tools as user-defined definitions). Tool search is GA on the Claude API, Claude Platform on AWS, Bedrock, and Vertex AI, and beta on Foundry — with one Bedrock caveat: server-side tool search works only through the InvokeModel API, not Converse. Managed Agents (rosters, overrides, vaults) is beta on the Claude API and Claude Platform on AWS only. One more documented behavior that matters at scale: on Managed Agents, an MCP tool result over 100K tokens is offloaded to a sandbox file automatically, with the agent receiving a preview and path.
Where to go next
Start with the single-server MCP pattern if you haven't, then see the tool search tool and vaults for the pieces this pattern composes.