MCP Tool Discovery and Dynamic Loading
How to split a large MCP tool catalog into a search index and runtime schemas, then retrieve and load only the tools needed for a task.
As a tool catalog grows, an agent needs a small discovery interface that can retrieve tools again instead of the full catalog in every prompt.
When schemas occupy the context
The Model Context Protocol (MCP) exposes server tools through a common protocol. Each tool has a name, a description, and a structured input schema. It may also define an output schema and execution properties.
If a client sends every definition to the model, input size grows with the number and size of the schemas. Token cost is only one consequence. Similar names and descriptions can make the model choose the wrong tool or overlook the required one.
The MCP tools specification defines tools/list as a paginated way to obtain tool definitions from a server. Collecting this catalog does not require exposing every schema in every inference call. The system can manage the full catalog while giving the model a task-specific subset.
Separating search from loading
A retrieve-then-load design separates fixed meta-tools from task-specific execution tools. The meta-tools remain visible and provide search and loading operations. An execution tool enters the model's callable set only after the system selects it from search results.
| Stage | Information visible to the model | System responsibility |
|---|---|---|
| Search | Name, short description, identifier | Compare queries with the index and return candidates |
| Select | Candidate capability and application | Choose required candidates and detect missing coverage |
| Load | Canonical input and output schemas | Bind selected tools to the current model call |
| Execute | Tool result or error | Recheck authorization and call the server |
Dynamic ReAct splits this flow into search_tools and load_tools. Search returns candidate descriptions and identifiers for atomic queries. The model chooses only the required identifiers and loads their runtime schemas.
The structural point is that search results do not all become callable tools. Search can favor candidate recall, while loading limits the final schemas that the model must compare.
Search documents and runtime schemas
A search index connects user wording to tool capabilities. It can embed one text representation built from the name, description, parameter descriptions, and metadata such as server or application. An embedding represents text as a numeric vector that supports semantic comparison.
A runtime schema is the contract for call arguments and results. A system may enrich descriptions for retrieval, but it should not treat the generated wording as an execution contract. It should use the result identifier to obtain the current canonical schema from the registry or MCP server before binding the tool.
| Concern | Search index | Runtime |
|---|---|---|
| Purpose | Find relevant candidates | Call a tool with valid arguments |
| Content | Retrieval text and filter metadata | Canonical name and input schema |
| Refresh | Reindex after catalog changes | Check the current contract before a call |
| Failure | Missing or misranked candidate | Validation error or incorrect execution |
An MCP server can advertise notifications for tool-list changes. A client can invalidate or rebuild its index after such a notification. Servers without that capability need another refresh rule, such as explicit versions or periodic synchronization.
Tools missing from the candidates
Finding one relevant tool is different from finding every tool required by a task. Hit Rate measures the share of queries with at least one relevant result in the top K. Recall measures the share of all relevant tools that the retriever returned.
Semantic Tool Discovery is a preprint posted to arXiv in March 2026. On the authors' benchmark of 5 servers, 121 tools, and 140 queries, Hit Rate at K=3 was 97.1%, while Recall at K=3 was 59.6%. A high hit rate alone does not show complete coverage for workflows that need multiple tools.
If retrieval omits a tool, the model cannot select what it never sees. A single search for a request spanning several systems may fill the highest ranks with candidates from only one domain. Decomposing the task into atomic operations and searching for each operation addresses this failure mode.
A production system should provide a bounded rediscovery path. It can reformulate the query when candidates lack a required capability or when loaded schemas cannot express the planned arguments. The system should cap broader searches and retries, then ask the user when the target remains ambiguous.
This rediscovery rule is an operational proposal rather than a measured result from either paper. It aims to recover omissions without allowing the agent to search indefinitely. A revised query should name the missing capability and target system from the current plan instead of repeating the original request.
The boundary between retrieval and authorization
Retrieval decides relevance, while authorization decides whether a call is allowed. Appearing in search results or being loaded does not grant execution permission. Combining these decisions can turn a stale index or incorrect metadata into an authorization bypass.
Before ranking, the system should filter the searchable catalog by user, organization, and connected account. Immediately before execution, it should recheck current credentials and action scope. Operations with side effects, such as writes or external sends, also follow the product's confirmation policy.
The MCP specification recommends an interaction model in which a person can deny tool invocations. Discovery must also avoid leaking private tool names and descriptions. Search filtering, execution authorization, and user confirmation therefore need separate controls and tests.
Practical evaluation
Offline retrieval evaluation measures candidate coverage. Record Hit@K and Recall@K together, along with Mean Reciprocal Rank (MRR) for the first relevant result. Separating single-tool queries from cross-server workflows helps expose failures hidden by an aggregate average.
Online evaluation measures what happens after retrieval. Track end-to-end task success, wrong tool calls, argument validation failures, rediscovery, and authorization denials separately. Search latency and schema tokens passed to the model reveal the tradeoff between cost and accuracy.
Compare full-catalog loading, immediate loading of the top K results, and selective loading after search. Test changed tool descriptions and registry updates as well. Include a case where an unauthorized tool is the closest semantic match but must still be excluded.
The figures in the two studies are starting points. Semantic Tool Discovery used one embedding model and a benchmark constructed by its authors. Dynamic ReAct also used its own registry and implementation, so production thresholds require measurements on the actual catalog and task distribution.
Summary
Large MCP catalogs can separate retrieval from loading instead of placing every schema in every model call. The search index represents candidates, while execution requires the current canonical schema and a separate authorization check. Because initial retrieval can omit required tools, the runtime needs bounded rediscovery and recall-oriented evaluation. As verified in September 2026, the two studies support the architecture, but each deployment must tune it against its own catalog and tasks.