An agent needs access to GitHub issues, a chat channel, and a monitoring system. You connect three MCP servers. Then you add a documentation server, a browser server, and another search tool because each looks useful. The agent now has more capabilities, but its next problem is deciding which tool to call, with which arguments, for one particular request.
This is the scaling problem behind MCP tool discovery. A connection is not free just because the tool is idle. Depending on the client, tool definitions may occupy context before the agent starts work, and similar tools can compete for the same request. The useful question is no longer just “Which servers can I connect?” It is “Which capabilities should this workflow expose right now?”
Discovery is not selection
MCP gives clients a way to discover tools from a server. The MCP architecture documentation describes listing available primitives, including tools, before invoking them. That tells a client what the server offers. It does not decide which tool is appropriate for a user request, whether two tools overlap, or whether a specific operation should be allowed.
A directory serves an earlier step. You can use AgentNDX to find candidate servers for a job, but a listing is not a live inventory of every tool exposed to your client, nor a benchmark showing that your agent will choose correctly. After connection, inspect the actual definitions and test the workflow with the credentials you intend to use.
The cost of loading everything
Anthropic’s advanced tool use write-up gives a concrete example: 58 tools across five servers consumed approximately 55,000 tokens of definitions before a conversation began. That is an example from its tooling, not a universal MCP overhead figure. Different clients load and present tools differently.
The same write-up describes a tool-search approach that loads relevant definitions on demand rather than placing every definition in the model’s context at once. Its internal evaluation found improvements in tool-use accuracy for the setups it tested. Those results do not mean every agent runtime has the same feature, or that simply hiding definitions will fix a poorly designed tool. The practical choice is whether to load tools up front or retrieve their definitions when needed.
There are two distinct failure modes to watch for. First, definitions can crowd out task data and conversation history. Second, an agent can select the wrong operation when several tools have similar names or descriptions. Lower token use helps the first problem; clear boundaries and task-level tests help the second.
Build a task-sized tool set
Start with a real workflow, not an inventory target. Suppose the request is: “Read the latest production error, find the issue that tracks it, and draft an update for the team.” You may need one monitoring read path, one issue search path, and one chat drafting path. You do not automatically need every write operation offered by those servers.
A practical selection loop looks like this:
- Name the task and its allowed outcome. Separate reading an error from changing an alert, and drafting a message from sending it.
- List candidate servers, then inspect live tools. Compare names, descriptions, required inputs, and access scopes in the client you will actually run. A directory description helps shortlist; the connected tool list tells you what is available now.
- Remove overlapping paths. If two tools both search issues, decide which one has the correct repository scope and more reliable results for this job. Keep the other available for a different workflow rather than asking the model to guess.
- Defer or restrict broad capabilities. If your client supports on-demand tool search or per-tool controls, use them. If it does not, connect fewer servers or narrow credentials. Do not assume a server’s advertised tool list is an enforcement boundary.
- Test ordinary and ambiguous requests. Check whether the agent chooses the right tool, supplies valid arguments, returns the needed evidence, and stops before a write that needs approval. Record failures, not only successful demos.
Anthropic’s tool-design guidance makes the complementary point: names, descriptions, and schemas affect tool choice. A short tool list with vague, overlapping descriptions can still fail. Good curation means defining clear jobs for tools and evaluating them against representative tasks.
What a directory can and cannot solve
Directories make discovery less random. They can help you compare candidates and follow a path to a maintainer’s documentation. They cannot see your runtime’s current credentials, measure the model’s tool choice in your application, or guarantee that a remote server’s exposed tools remain unchanged. For changes after connection, see our guide to reviewing MCP tool-list changes.
A useful directory entry should help answer the pre-install questions: What job does the server do? Who maintains it? What setup and auth does it require? The post-install questions belong to the client and operator: What tools appeared? What can those credentials touch? Which task tests passed? Treat those as separate checks, not one trust badge.
FAQ
Does connecting more MCP servers always use more model tokens? No. Some clients load tool definitions up front; others may defer them or use search. Inspect your runtime’s behavior rather than assuming one universal cost model.
Is tool search the same as an MCP server directory? No. A directory helps you discover and compare servers before connecting. Runtime tool search helps an agent find relevant tools among those available to its client during a task.
Should I install only one server per workflow? Not necessarily. Cross-system work may need several. Keep the smallest set that completes the job reliably, then test the handoff between them and constrain write authority separately.
If the agent finds the right issue but sends the update instead of drafting it, another connected server did not help. Test the boundary between reading and acting, not just whether the tools are available.