I Cut Initial MCP Context by 97%—and Made One Workflow Slower

At the experiment snapshot, I had a number I wanted to celebrate: 142 MCP tools. FORMLOVA's current public registry contains 138 tools as of August 13, 2026; the measurements below remain tied to that historical 142-tool snapshot.

FORMLOVA had grown from a form-creation tool into a form-operations product. The registry covered responses, reminders, email, reports, workflows, payments, and team operations. Every new tool meant another real task the connected AI could perform.

Then I measured what the registry asked the model to read before the user had asked for any of it.

The shared instructions, tool descriptions, and parameter descriptions in the source totaled 107,476 characters. A rough four-characters-per-token estimate put that at about 26,869 tokens, before the full structural cost of the schemas.

It was not an exact bill. It was enough to change the question.

Instead of asking, “How many tools can we expose?” I started asking, “How many tool definitions should enter this conversation now?”

The experiment

I did not want to shrink the product to improve the prompt.

The baseline and candidate both kept the same 142-tool registry. In the baseline, the tool surface was loaded statically. In the candidate, the host initially exposed ToolSearch, the model discovered the relevant definitions, and then called the native tools.

I tested three request types:

• a common operation;
• a long-tail operation;
• a request that needed no tool.

After rejecting calibration mistakes and resetting the count, the formal capability gate completed 30 valid runs.

The median initial input fell by about 97.6 percent.

| Request | Baseline | Candidate | Change |
|---|---:|---:|---:|
| Common | 63,258 tokens | 1,509 tokens | -97.61% |
| Long-tail | 63,270 tokens | 1,521 tokens | -97.60% |
| No tool | 63,175 tokens | 1,426 tokens | -97.74% |

The candidate still reached the expected native tools. The common and long-tail runs used discovery once. The no-tool runs used neither discovery nor a native tool.

This looked like a clean win until I checked wall time.

The common path became 1.96 seconds slower

The common operation went from a median of about 8.48 seconds to 10.44 seconds.

The long-tail operation was about 0.17 seconds slower. The no-tool request was about 0.96 seconds faster.

The reason is simple: discovery is work. The common path needed another search and another turn before doing the obvious thing.

I could have reported the 97.6 percent reduction and moved on. That would have produced a better launch sentence and a worse product decision.

The useful result was the contradiction.

Fewer initial tokens did not automatically create a faster workflow.

The decision changed from a switch to a policy

I stopped treating progressive discovery as something to enable for every request.

The policy I am moving toward is hybrid:

• keep a small eager set for frequent, obvious operations;
• defer specialized tools until the request points toward them;
• let conceptual questions remain no-tool questions;
• keep a static fallback for hosts that do not support deferred loading;
• measure latency separately for common, long-tail, and no-tool requests.

This sounds less exciting than “we cut context by 97 percent.” It is much more useful.

It also changed how I think about product breadth. Tool count is an inventory metric. It tells me what FORMLOVA can do. It does not tell me what an agent should consider in every conversation.

Capability and attention need separate designs.

What I would measure before adding the next 100 tools

If you are building an agent product with a growing integration surface, I would record five things before optimizing the catalogue:

1. the size of the definitions as the host actually presents them;
2. whether the registry is identical between baseline and candidate;
3. whether discovery returns the exact target tools;
4. whether the native calls happen in the required order;
5. token and latency changes for common, long-tail, and no-tool requests.

Do not accept a plausible final answer as proof that discovery worked. Do not infer model-context behavior from a registry event that only proves the host knows a tool exists. Do not average all requests together and hide the slow path.

I wrote up the complete measurement and its limitations here: More Connections Do Not Always Make AI Smarter.

The number I am proudest of now is neither the registry count nor 97.6 percent.

It is the 1.96-second regression we did not hide, because it forced a better policy.

How are you deciding which capabilities your agent sees eagerly and which ones it has to discover?

Disclosure and Verification

I build FORMLOVA. These are conditional results from FORMLOVA's July 2026 source audit and formal Claude Phase 1 capability gate. They are not universal benchmarks for every model, host, or MCP registry.