An MCP server can expose a large, useful tool surface and still make an agent worse at the task in front of it.
The failure is not necessarily in the tools. It can happen before the first tool call, when every name, description, and input schema competes with the user's request for the same model context.
I ran into this while working on FORMLOVA, a form-operations MCP server. The experiment used a 142-tool registry snapshot. FORMLOVA's current public registry contains 138 tools as of August 13, 2026, so the measurements below should be read as results for that historical 142-tool snapshot. I did not want to remove capabilities just to make the initial prompt smaller. I wanted the host to keep the same registry available while loading definitions only when a request needed them.
That sounds like a simple tool-search feature. It is not.
The implementation has three separate layers, and the result has at least four things to verify:
- the full registry remains available;
- the model can discover the relevant definitions;
- discovery leads to the exact intended tool calls;
- the token reduction does not hide a latency or reliability regression.
Here is the architecture and the measurement that changed how I think about large MCP servers.
First, measure the surface you already have
I started with a source-level inventory rather than a model invoice.
The shared MCP instructions, public tool descriptions, and parameter descriptions in the FORMLOVA source totaled 107,476 characters. Dividing by four gives a rough estimate of 26,869 tokens.
That number is intentionally imprecise.
It is not a live-tokenizer measurement. It excludes part of the structural cost of the generated JSON Schema. Different hosts serialize definitions differently. Prompt caching can change billed input. The value is useful as a lower-bound engineering signal, not as a cost claim.
The important question was not whether the estimate was exact. The important question was whether this much tool material needed to enter the initial model input for every request.
Consider three requests:
- list two forms and inspect one of them;
- find an uncommon workflow operation;
- explain a concept without calling any tool.
The first request probably needs two familiar definitions. The second needs discovery. The third needs none. A static all-tools prompt treats all three as if they require the whole registry.
That is the allocation problem.
Do not collapse three discovery layers into one
Most confusion in this area comes from using “tool discovery” to describe different operations.
Layer 1: the server registry
The server owns the tool contracts. It defines names, descriptions, input schemas, annotations, and execution behavior.
FORMLOVA still had 142 tools in both sides of the experiment. Progressive discovery did not mean deleting 140 tools and pretending the system had improved.
Layer 2: MCP protocol discovery
MCP clients use tools/list to retrieve tool definitions from a server. The protocol defines how the registry is exposed. It does not, by itself, prove how a particular host places those definitions into a model prompt.
This distinction matters because a successful tools/list response tells you the client received definitions. It does not tell you that every schema entered the model context, or that none did.
Layer 3: host-side model exposure
The host decides what the model sees and when.
A host can register a large set of tools while initially exposing only a discovery surface. The model searches for relevant definitions, the host returns references or selected schemas, and the model then calls the target tools.
That is the layer where initial context can actually change.
A server-side helper such as search_tools can still be useful. It can give the model semantic navigation inside a large product surface. But it does not prove that the host deferred the other definitions. If all schemas were already loaded, server-side search is navigation after allocation, not allocation itself.
The candidate flow
The candidate flow I tested looked like this:
User request
-> host exposes ToolSearch
-> model searches the registered tool set
-> host returns references to relevant tools
-> model receives selected definitions
-> model calls the exact target sequence
For a common read-only fixture, the expected native sequence was:
ToolSearch
-> list_forms
-> get_form
The validation did not stop at “the final answer looked right.” The harness checked that discovery happened, that references included the targets, that the native calls occurred in the required order, and that unapproved tools were not used.
This is important for any tool-search evaluation. A model can produce a plausible sentence without executing the operation you intended. It can also find a semantically nearby tool that returns similar-looking data. Functional output alone is too weak a contract.
Keep the baseline and candidate registry identical
If the baseline has 142 tools and the candidate has 12, you are testing capability removal as much as progressive discovery.
I kept the same registry across both conditions and verified the tool-name and definition digests before and after the run. The variable was how the host exposed definitions to the model.
The formal Phase 1 capability gate covered three prompt types:
| Prompt type | Why it exists |
|---|---|
| Common tool | Tests an obvious operation whose definition is easy to find |
| Long-tail tool | Tests whether discovery still reaches a less obvious operation |
| No tool | Tests whether the model avoids unnecessary search and tool calls |
Each prompt ran repeatedly in baseline and candidate conditions. After calibration failures were isolated and the count was reset, the formal artifact contained 30 expected runs, 30 observed runs, and no missing or skipped run.
The calibration history matters. One early prompt confused a native server tool with the host's ToolSearch surface. Another interpretation treated an initialization name list as proof of schema injection. Both were rejected rather than blended into the final numbers.
If you cannot explain what an event proves, do not use it as a metric.
The result: much smaller initial input
Median initial input fell sharply in the candidate condition.
| Prompt | Baseline initial tokens | Candidate initial tokens | Reduction |
|---|---|---|---|
| Common | 63,258 | 1,509 | 97.614531% |
| Long-tail | 63,270 | 1,521 | 97.596017% |
| No tool | 63,175 | 1,426 | 97.742778% |
The same 142-tool registry remained available. The candidate used ToolSearch exactly once in the common and long-tail runs. It used neither ToolSearch nor a native tool in the no-tool runs.
This is the result people like to put in a headline. It is also only half the result.
The uncomfortable result: the common path got slower
The common-tool request was about 1.960 seconds slower in the candidate condition.
| Prompt | Baseline median wall time | Candidate median wall time | Difference |
|---|---|---|---|
| Common | 8.476 s | 10.437 s | +1.960 s |
| Long-tail | 11.254 s | 11.419 s | +0.165 s |
| No tool | 4.420 s | 3.465 s | -0.956 s |
The likely explanation is not mysterious. Discovery adds work. The common request needed an extra search and an extra turn before the native calls. A smaller initial prompt did not erase that overhead.
This changed the conclusion.
The conclusion is not “tool search makes MCP faster.” It is not even “tool search is always better.”
The conclusion is that progressive discovery can preserve a large capability registry while allocating far less initial context, but the latency tradeoff depends on the request type.
For an obvious operation that users call constantly, a small eager set may be better. For long-tail operations, progressive discovery can be worth the extra lookup. For no-tool questions, avoiding the entire registry can help both context and time.
A practical hybrid policy
The measurement points toward a hybrid policy rather than one global switch.
Keep a small eager set
Choose tools using observed request frequency, not internal importance. A tool can be central to the product and still be rare in conversations.
The eager set should contain operations where an extra discovery turn creates noticeable friction and where the definitions are small and stable.
Defer the long tail
Keep specialized tools registered but load their definitions only after discovery. This preserves capability without charging every conversation the same initial-context cost.
Let no-tool requests stay no-tool
A discovery surface should not become a mandatory ritual. If the request is conceptual, the agent should answer without searching the registry.
Keep a static fallback
Not every host supports deferred loading or exposes enough evidence to verify it. A server should continue to work with clients that load definitions statically. Progressive discovery is a host capability, not a reason to break protocol compatibility.
What to log in your own experiment
At minimum, record the following for each condition:
registry tool count
tool-name digest
tool-definition digest
discovery call count
discovery result references
native tool names and order
functional assertions
safety assertions
initial input tokens
total input tokens
provider latency
host end-to-end latency
turn count
Do not combine provider latency with native tool execution subtotal. Do not infer schema injection from a UI event that only proves registration. Do not count a failed calibration prompt as a valid performance run.
Most importantly, separate common, long-tail, and no-tool requests. An aggregate average can hide the exact tradeoff you need to make.
The design rule I kept
A tool registry is a capability inventory. The initial prompt is a memory allocation decision.
MCP gives a server a standard way to expose tools, but the agent experience depends on what the host does with those definitions. Large servers need good tool contracts, good discovery, and evidence that the selected tools still execute correctly. None of those replaces the others.
The full FORMLOVA measurement, including the source-level footprint, host boundaries, and limitations, is in More Connections Do Not Always Make AI Smarter.
If you are building a large MCP server, I would test one common request, one long-tail request, and one no-tool request before turning progressive discovery into a global policy. The uncomfortable number may be the most useful one.
Disclosure and Verification
I build FORMLOVA. The measurements in this article come from FORMLOVA's July 29, 2026 source audit and formal Claude Phase 1 capability gate. They are conditional results for the recorded registry, prompts, model, and host configuration, not a benchmark for every MCP implementation.
Primary references:
Top comments (0)