What Is MCP Tool Search, and When Do You Need It?

The problem it solves

When an agent connects to an MCP server, the client usually lists every tool the server exposes and passes those definitions to the model: names, descriptions, and input schemas. The model needs them to decide what to call.

That works with ten tools. It degrades with two hundred. Every definition is context, sent with every request, whether or not the task needs it. Connect a few servers for a database, a ticket system, a cloud provider, and internal APIs, and a meaningful share of the context window is tool descriptions before the user has said anything.

There is a second cost. Models choose tools less reliably as the list grows, especially when several tools have similar names or overlapping descriptions. The wrong tool gets called, or the right one gets called with the wrong arguments.

How tool search works

The agent starts with one small tool whose job is to find other tools. When the model needs a capability, it calls that search tool with a description of what it wants to do. The search returns a short list of matching tool definitions, which are then made available for the model to call.

The search itself can be simple keyword matching over tool names and descriptions, or semantic search over embeddings of those descriptions. Semantic search handles the common case where the model describes the task in different words than the tool author used.

The pattern is showing up in several places at once: model providers offering deferred tool loading, agent clients supporting it, and server frameworks building it in so large servers can expose a searchable catalogue by default.

When it is worth adding

Add it when the client connects to many servers, a single server exposes a large surface such as an API wrapped operation by operation, or you see the model picking the wrong tool among similar ones.

Skip it when a server has a handful of distinct, well-described tools. The search step adds a round trip and a small chance the right tool is not returned. For a small surface, loading everything is simpler and just as accurate.

Fix descriptions first. Tool search ranks on descriptions. Vague ones such as "handles records" will be found no more reliably by search than by the model scanning a list. Write descriptions that state what the tool does, what it needs, and when to use it instead of its neighbours.

Designing a server that works well with search

If you build MCP servers, a few choices make the difference between tools that search finds and tools that disappear.

One tool per task, not per endpoint. Wrapping every API operation as its own tool produces a huge, repetitive catalogue. Group operations into tools that match how an agent thinks about the work, such as search orders or refund an order, with parameters for the variants.

Descriptions that say when. State what the tool does, what inputs it needs, and when to prefer it over a similar tool. The last part is what separates neighbours during ranking.

Stable, specific names. A name like orders search is easier to match than a generic query tool, whether the matching is keyword or semantic.

Small, predictable outputs. Search solves the definition side of the context problem. Oversized responses recreate it on the result side, so paginate and return only the fields the agent asked for.

The same idea, applied to knowledge

Tool search is retrieval applied to capabilities. The principle is the one behind retrieval over documents: do not load everything into context in case it is needed; index it and fetch what the task requires.

Agents that load tool catalogues on demand but still paste whole documentation sets into prompts are solving half the problem. Index the knowledge the same way, and the agent pulls the relevant chunks instead of paying for the whole library on every request.