Tool Invocation at Scale: The Server Manager

~12 min read

The Server Manager keeps an agent's active toolset intentionally narrow and context-driven — loading tools dynamically, only when needed, instead of exposing everything from every server at once.

Given the 3 tool-overload failure modes from the previous subtopic, mcp-use includes a built-in Server Manager, which directly addresses the common failure modes agents face when interacting with large or multi-server toolsets.

The core idea: instead of exposing every tool from every server at once — something that often leads to tool-name hallucinations, confusion between similar tools and degraded reasoning — the Server Manager keeps the agent's active toolset intentionally narrow and context-driven. Rather than dumping the full combined tool list from every connected server into the LLM's context on every turn, the Server Manager decides, dynamically, which subset is actually relevant right now.

Concretely, when enabled, the Server Manager: loads tools dynamically, only when needed; discovers which server is appropriate for the task; keeps the active tool list small and focused, reducing model overwhelm; updates tools in real time as servers connect or disconnect; and provides semantic search over all available tools across servers (so relevant tools can still be found even though they aren't all loaded into context upfront). Enabling it is as simple as setting use_server_manager=True on the agent.

With this, agents no longer need to juggle dozens of tools at once. The Server Manager becomes the orchestrator — deciding which server to activate, which tools to load, and when to surface them — resulting in clearer tool selection and more stable agent behavior across multi-server environments.

This is the mechanism that makes 'tool invocation' actually reliable at scale: rather than every tool call competing against dozens of others in a single flat list (the root cause of all 3 failure modes), the Server Manager narrows what's presented to the LLM at the moment a decision is actually being made, directly addressing the cognitive-load and disambiguation problems at their source rather than relying on better prompting alone to work around them.

💻 Code example

# Conceptual illustration of the Server Manager's dynamic,
# context-driven tool loading -- narrowing what's in context per turn.
from mcp_use import MCPAgent, MCPClient
from langchain_openai import ChatOpenAI

async def build_agent_with_server_manager():
    client = MCPClient.from_config_file("multi_server_config.json")  # connects to several servers
    llm = ChatOpenAI(model="gpt-4o")

    agent = MCPAgent(
        llm=llm,
        client=client,
        use_server_manager=True,  # <- keeps active toolset narrow and context-driven
    )

    # Under the hood, the Server Manager:
    #   1. discovers which connected server is relevant to this query
    #   2. loads ONLY that server's tools into context (not all servers' tools)
    #   3. uses semantic search to still find the right tool if unsure
    result = await agent.run("Book a flight to Tokyo for next Friday")
    return result

import asyncio
print(asyncio.run(build_agent_with_server_manager()))

💬 Deep Dive with AI

Key points

  • The Server Manager keeps the agent's active toolset intentionally narrow and context-driven, rather than exposing every tool at once
  • It loads tools dynamically only when needed, and discovers which server is appropriate for the current task
  • It provides semantic search over all available tools across servers, even ones not currently loaded into context
  • Enabling it is as simple as setting use_server_manager=True on the agent
  • It becomes the orchestrator deciding which server to activate and which tools to surface, directly addressing tool overload at its source