Last updated: July 31, 2026
Connecting an AI application to more services increases the set of things it can do. It does not guarantee that the model will choose those capabilities well.
If every available tool definition enters context before the user’s request, the model spends part of its context window on names, descriptions, and schemas that may never matter to the task. User instructions, conversation history, retrieved evidence, and working state all have to compete with that catalog.
I measured this problem in the FORMLOVA source. The shared MCP instructions, tool descriptions, and Zod parameter descriptions total 107,476 characters. Using the deliberately rough estimate of four characters per token, that is about 26,869 tokens. It is not a live-tokenizer measurement, and it excludes the structural cost of the JSON Schema itself, so it should be treated as a lower-bound auxiliary signal rather than a billing number.
I then ran a formal 30-run capability gate with Claude Sonnet 5. Median initial input tokens fell by 97.59% to 97.74% across three prompts. The common-tool prompt, however, became about 1.960 seconds slower. The conclusion is not “tool search always makes MCP faster.” It is that a host kept the same 142 tools available in that July 29 experiment while reducing initial context, but the benefit and latency need to be measured by condition.
This article is not another general definition of an MCP form service. The broader category is organized in the MCP Form Service Guide, while the post-publish operations thesis belongs to MCP Form: Form Builder vs Form Operations. Here, the question is narrower: when a server exposes a large tool library, which definitions should enter the model’s context, and when?
The Short Answer: Count Definitions, Not Just Connections
The official Model Context Protocol introduction describes MCP as an open standard for connecting AI applications to external systems. That standardization is useful. A single AI host can reach documents, calendars, databases, form operations, and other services through a common protocol.
But MCP does not make a large tool catalog context-free.
An MCP server returns available tool definitions through tools/list. A host still has to decide whether it will put every returned definition into the model’s prompt, defer most definitions, or expose a smaller search surface first. Loading everything is reasonable for a small catalog. It becomes expensive when one host reaches hundreds or thousands of tools across many servers.
This means four quantities should remain separate:
Capabilities the host can reach
Definitions the model sees before the task
Data required while executing the task
Actions that require human approval
The first can keep growing without forcing the second to grow at the same rate.
What FORMLOVA's Source Measurement Includes
FORMLOVA currently exposes 138 public MCP tools across 24 categories. They cover form creation, publishing, response operations, email, analytics, workflow configuration, tool discovery, and LINE operations. FORMLOVA also maintains 50 official Workflow recipes so a person can begin with a business outcome instead of a raw function name.
The July 29 source-level measurement reported 143 tools, while the public surface at that time had 142. The additional entry was record_conversation_trace, an internal conversation-trace recorder included in the internal registration and health inventory. That historical measurement is separate from the current 138-tool public product count.
On July 29, 2026, npm run mcp:token-footprint produced this result:
| Source-level component | Characters | Approximation at 4 chars/token |
|---|---|---|
| MCP INSTRUCTIONS | 30,741 | 7,686 tokens |
| Tool descriptions, including 143 internal entries | 54,818 | 13,705 tokens |
Zod .describe() parameter text | 21,917 | 5,480 tokens |
| Total | 107,476 | 26,869 tokens |
The script parses string content in the source. It does not serialize a real tools/list response and run that response through a provider tokenizer. It does not count property names, types, enum values, required arrays, or the surrounding JSON Schema structure. Two .describe() calls could not be reduced to static string literals and are also outside the total.
The result therefore does not mean that every FORMLOVA client pays exactly 26,869 input tokens on every turn. Hosts differ in how they handle server instructions, transform schemas, cache tool definitions, and select tools. Tokenizers differ too.
What the result does show is that descriptive text alone becomes a material context allocation at this scale. Depending on host transformation and serialization, the actual transferred definition may be larger than the strings counted here.
Tools, Resources, and Prompts Have Different Control Models
A large MCP connection should not be treated as one box whose contents must all be placed in front of the model.
The official guide to understanding MCP servers separates three core building blocks:
| MCP feature | Purpose | Primary control model |
|---|---|---|
| Tools | Operations a model can request | Model-controlled |
| Resources | Context data an application can select and retrieve | Application-controlled |
| Prompts | Reusable templates a person explicitly chooses | User-controlled |
This distinction is also a context-allocation model.
An application can search Resources, select relevant portions, and decide what enters context. A user can explicitly choose a Prompt that matches the intended workflow. A host can make Tools available without putting every full tool definition into the model’s initial context.
FORMLOVA’s 50 official Workflow recipes are a product-level discovery layer, not an implementation of protocol-level tool search. They help a person find an operational outcome and copy a prompt. The Workflow Place guide explains that path. The recipes do not, by themselves, reduce the set of tool definitions a host injects into a model.
Human discovery and model discovery are related, but they are not the same mechanism.
Keep All 138 Native Tools, and Let the Host Load What It Needs
This is the boundary that is easiest to miss.
FORMLOVA does not expose a separate lightweight MCP endpoint. It keeps one /api/mcp, all 138 native tools, the existing tools/call paths, complete schemas, and safety checks. The variable is whether the host injects every definition before the task or loads only the definitions it needs.
FORMLOVA's search_tools and get_tool_details are authenticated, read-only discovery capabilities. The first returns short metadata for candidates; the second returns one candidate's complete registered definition. Those two server tools do not reduce initial schema by themselves. If the host injects all 138 definitions before it can call them, the initial context has already been spent. In the Claude result below, Claude Code's host-side ToolSearch produced the initial reduction.
The official OpenAI Tool Search guide instructs Responses API developers to add tool_search and set defer_loading: true on the MCP definition. It is supported by GPT-5.4 and later models. The model initially sees the MCP server name and description, then searches and loads individual function definitions when needed.
The official Claude Code MCP documentation says ToolSearch is enabled by default. MCP definitions are deferred and relevant tools are discovered on demand. The search step adds a round trip, so small tool sets or some prompts can be faster with upfront loading. This is not a universal latency optimization.
The verified boundaries by host are:
| Host | What was verified by July 29, 2026 | What remains unverified |
|---|---|---|
| Claude Code | Formal 30-run ToolSearch gate with the same 142 tools | Critical 6 / Formal 60 performance gate |
| OpenAI Responses API | Official tool_search + MCP defer_loading: true, GPT-5.4+ | Formal FORMLOVA token and latency results |
| Codex | Functional discovery and native-tool reachability | Token reduction |
| ChatGPT Web | Read-only functional UX success | ToolSearch, progressive discovery, exact trace, and provider tokens |
A common design has three layers:
- Catalog: search names and short capability summaries.
- Inspect: retrieve the complete definition for a small candidate set.
- Execute: call the selected tool and apply the appropriate approval policy.
The server still has important responsibilities. Tool names need to describe the work clearly. Descriptions need enough discriminating detail to be searchable. Schemas need to be typed correctly. Permissions and safety annotations need to reflect the impact of the operation.
The host has a different responsibility. It decides which capabilities are eligible for this user, which definitions fit the current request, how much context is available, and which tools should remain visible at all times.
Progressive discovery should not become a blanket rule that hides everything. If publishing, sending, or recovery tools are impossible to find, the agent cannot complete the job. A practical host usually needs:
- a small set of always-visible, high-frequency tools;
- a searchable long tail;
- access-control filtering before retrieval;
- full schemas loaded only for selected candidates;
- approval before externally consequential actions.
This preserves capability without making every capability pay rent in every prompt.
What the Formal Claude 30-Run Gate Found
On July 29, 2026, FORMLOVA compared Baseline and Candidate conditions with claude-sonnet-5, the same 142-tool registry, and source commit bdfc4ffd. Three prompts covered a common tool, a long-tail tool, and no tool. Each prompt-condition pair ran five times. The gate recorded expected 30 / observed 30, missing 0, and skipped 0. Every run passed status, functional assertions, and Safety assertions.
Initial tokens and Total input come from Claude's provider-reported usage. The prompt-level medians were:
| Prompt | Initial tokens, Baseline→Candidate | Total input, Baseline→Candidate | Wall latency, Baseline→Candidate |
|---|---|---|---|
| common | 63,258 → 1,509 | 126,968 → 11,197 | 8.476s → 10.437s |
| long-tail | 63,270 → 1,521 | 127,323 → 10,620 | 11.254s → 11.419s |
| no-tool | 63,175 → 1,426 | 63,175 → 1,426 | 4.420s → 3.465s |
| Prompt | Initial reduction | Total reduction | Latency difference |
|---|---|---|---|
| common | 97.614531% | 91.181243% | +1.960457s |
| long-tail | 97.596017% | 91.659009% | +0.165039s |
| no-tool | 97.742778% | 97.742778% | -0.955896s |
The Candidate called ToolSearch exactly once in every common and long-tail run, then reached the expected native tool. It called neither ToolSearch nor a native tool in the no-tool runs. The single /api/mcp, all 142 native tools, and the definition digest remained unchanged. This was not a server-side lite variant.
Latency did not improve uniformly. The common prompt was about 1.960 seconds slower, the long-tail prompt about 0.165 seconds slower, and the no-tool prompt about 0.956 seconds faster. The balance between an extra search round trip and a smaller initial context depends on the prompt.
This was a capability gate. It tested whether the host could find the required tool, avoid unnecessary calls, and preserve safety. The Critical 6 scenarios with five repetitions per condition, or Formal 60, are not complete. These percentages therefore must not be generalized to every workflow, OpenAI, Codex, or ChatGPT, and they do not establish that the product is faster overall.
Anthropic's 85% Example Is Supporting Evidence, Not the FORMLOVA Result
Anthropic published a useful primary-source example in Introducing advanced tool use.
In that example, loading all definitions for more than 50 MCP tools consumed about 77K tokens before work began. With its Tool Search Tool, total context consumption fell to about 8.7K tokens, an 85% reduction. Anthropic also reports accuracy improvements in its internal MCP evaluations.
Those numbers describe Anthropic’s setup and internal testing. They are separate from the formal FORMLOVA 30-run gate above and do not share its measurement boundary.
FORMLOVA’s approximately 26,869 tokens come from source strings divided by four characters per token. Anthropic’s 77K and 8.7K figures describe total context consumption in its tool-search example. The catalogs, system prompts, schemas, tokenizer, host behavior, and measurement boundaries are different. It would be incorrect to infer that FORMLOVA will receive the same 85% reduction.
The transferable part is the sequence:
Keep the complete library available
Do not inject the complete library upfront
Search for a task-relevant candidate set
Expand full definitions only when needed
That sequence protects context without deleting capabilities.
Tool Count Is a Capability Metric, Not an Intelligence Metric
FORMLOVA did not reach 138 public tools to win a catalog-size contest. The surface became large because post-publish form operations are large.
A real form workflow may need to create a draft, review previews, publish with confirmation, search responses, change status, filter sales pitches, analyze results, prepare reminders, inspect delivery, export files, and route selected records. Those are different operations with different inputs and different safety boundaries.
The catalog is evidence that the service can reach that work. It does not prove that any model will select the right operation from an unfiltered list.
The same distinction applies to the 24 categories and 50 official Workflow recipes. Categories improve naming and navigation. Recipes let a person begin with an outcome such as event follow-up or inquiry escalation. Neither automatically changes what an external host places in model context.
For an MCP-native product, capability design and context-delivery design are separate product surfaces:
| Product question | What needs to be designed |
|---|---|
| What can the service do? | Tools, schemas, responses, and safety boundaries |
| How does a person find a useful workflow? | Categories, examples, recipes, and documentation |
| How does a model find a useful tool? | Host-side search, ranking, access filters, and selective expansion |
| How is impact controlled? | Approval, authorization, logging, and recovery |
Improving only the first row eventually makes the third row harder.
MCP 2026-07-28 Is Now the Official Specification
Context selection also needs to remain separate from protocol state.
The official MCP post that originally described the 2026-07-28 specification release candidate covered a stateless protocol core, first-class Extensions, Tasks changes, authorization hardening, and other revisions. That release candidate has since become the official specification, with Tier 1 SDK support in place. It replaces 2025-11-25 as the current stable revision.
Implementers should now treat 2026-07-28 as the current stable specification rather than a preview.
The stateless core removes the protocol’s dependence on implicit connection sessions and makes ordinary HTTP routing, caching, and tracing easier. It does not mean that an AI forgets business state. Authentication, a form draft, a workflow run, and user permissions still need explicit application-level ownership.
It also does not automatically reduce model context. Making tools/list easier to cache is different from deciding whether every cached definition enters a prompt. Protocol transport and model-context policy solve different problems.
Six Decisions to Make Before Adding More Tools
The FORMLOVA measurement led me to six practical checks for large MCP surfaces.
| Decision | What to verify |
|---|---|
| Measure components separately | Track instructions, tool descriptions, parameter text, and serialized schema instead of one unexplained total |
| Define a threshold | Decide what percentage of the model context can be spent on tool definitions before progressive discovery activates |
| Filter before search | Remove tools the user, plan, role, or environment cannot call before ranking candidates |
| Keep a small core visible | Preserve frequent status, authentication, search, and recovery capabilities |
| Separate impact levels | Treat read operations differently from publishing, sending, deleting, or external writes |
| Validate by condition | Measure tokens, selection accuracy, latency, and recovery behavior for each prompt and supported host |
Categories, Workflow recipes, and server-side search_tools help people and models find a capability. They do not by themselves shrink initial schema. The host must enable deferred loading, and the evaluation must measure tokens, latency, success, and safety together.
Live evaluation should also measure more than token count. A smaller prompt that selects the wrong tool is not an improvement. A search layer that adds too much latency may not feel better. A permission filter that hides the recovery path can make failures worse.
The target is not the fewest visible tools. The target is the smallest sufficient tool set for the current task.
Context Allocation Is Now Part of AI Product Design
MCP became one of the founding project contributions to the Linux Foundation’s Agentic AI Foundation in December 2025. As a shared ecosystem standard, it can support more clients, more servers, and many more available operations.
That makes one distinction increasingly important:
Everything can be connected
does not mean
everything should be shown to the model now
FORMLOVA’s 138 public tools describe the breadth of form operations an MCP client can reach. In the Claude 30-run gate, one MCP endpoint kept all 138 tools available while the host found the necessary definitions and materially reduced initial tokens. The common prompt also became slower, and Critical 6 / Formal 60 remains incomplete. Capability, context, latency, and safety still have to be evaluated together before the catalog becomes dependable operational value.
The value of MCP is not unlimited information in the prompt. It is continued access to the external world while context remains allocated to the work in front of the user.
Primary Sources
- Model Context Protocol: What is MCP?
- Model Context Protocol: Understanding MCP servers
- Model Context Protocol: Client Best Practices
- OpenAI API: Tool search
- OpenAI API: MCP and Connectors
- Claude Code: Scale with MCP tool search
- Claude Agent SDK: How tool search works
- Anthropic: Introducing advanced tool use
- Model Context Protocol Blog: The 2026-07-28 MCP Specification Release Candidate (note: the 2026-07-28 revision has since become the official specification, with Tier 1 SDK support)
- Model Context Protocol GitHub Releases
- Linux Foundation: Formation of the Agentic AI Foundation
Setup guide: Connect FORMLOVA to your MCP client
Disclosure and Verification
This article was written by a FORMLOVA developer after checking the FORMLOVA specification, MCP tool-registration source, static footprint script, the formal Claude Phase 1 artifact from source commit bdfc4ffd, and the official MCP, OpenAI, Claude, and Anthropic sources above on July 29, 2026. The current public product count is 138 tools across 24 categories, with 50 official Workflow recipes. The July 29 internal static measurement had 143 entries and included record_conversation_trace. Four characters per token is a rough estimate, not a live tokenizer result. The Claude result is a 30/30 capability gate; Critical 6 / Formal 60 performance testing is incomplete. Token reduction is not measured for Codex. For ChatGPT Web, only read-only functional UX success was verified; ToolSearch, progressive discovery, exact traces, and provider tokens remain unverified. MCP 2026-07-28 was officially released on July 28, 2026 (with Tier 1 SDK support) and is now the current stable specification.
