Last updated: July 28, 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 110,220 characters. Using the deliberately rough estimate of four characters per token, that is about 27,555 tokens. It is not a live-client measurement, and it excludes the structural cost of the JSON Schema itself, so it should be treated as a lower-bound signal rather than a billing number.
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 140 public MCP tools across 26 categories. They cover form creation, publishing, response operations, email, analytics, workflow configuration, 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 source-level measurement reports 141 tools, not 140. The additional entry is record_conversation_trace, an internal conversation-trace recorder included in the internal registration and health inventory. It is not part of the 140-tool public product count. Keeping those two numbers separate matters: one describes the public surface, while the other describes the source inventory measured by the script.
On July 28, 2026, npm run mcp:token-footprint produced this result:
| Source-level component | Characters | Approximation at 4 chars/token |
|---|---|---|
| MCP INSTRUCTIONS | 34,072 | 8,518 tokens |
| Tool descriptions, including 141 internal entries | 54,330 | 13,583 tokens |
Zod .describe() parameter text | 21,818 | 5,455 tokens |
| Total | 110,220 | 27,555 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 27,555 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. The complete serialized definition can only add structural material beyond 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.
tools/list Is Discovery, but It Is Not Progressive Injection
This is the boundary that is easiest to miss.
The FORMLOVA MCP server does not currently implement a server-side search_tools meta-tool. Its tools/list surface returns all 140 public tools. The connected host decides whether all definitions enter model context or whether only a task-relevant subset is expanded.
The official MCP Client Best Practices treats this as a host-scaling problem. A host can fetch the catalog through tools/list normally, defer injecting full definitions, expose a lightweight search mechanism, and add complete schemas only when a task requires them. The guide calls this progressive discovery.
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.
Anthropic's 85% Reduction Is an Internal Example, Not a FORMLOVA Benchmark
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 not FORMLOVA results.
FORMLOVA’s approximately 27,555 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 140 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 26 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 Still a Release Candidate
Context selection also needs to remain separate from protocol state.
The official MCP post on the 2026-07-28 specification release candidate describes a stateless protocol core, first-class Extensions, Tasks changes, authorization hardening, and other revisions. As of July 28, 2026, the official GitHub Releases page still marks 2026-07-28 as a pre-release. The stable revision is 2025-11-25.
“Release candidate” matters here. Implementers can evaluate the new design, but they should not describe it as the current stable specification.
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 in a real host | Measure tokens, selection accuracy, latency, and recovery behavior in each supported client |
The last check is essential. A static footprint is an engineering baseline, not an end-to-end result. It can identify growth and likely pressure. It cannot tell us how Claude, ChatGPT, Cursor, or another host caches definitions, ranks candidates, or recovers from a wrong choice.
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 140 public tools describe the breadth of form operations an MCP client can reach. Whether an AI uses that breadth well is a separate architecture problem. The host needs to find the few relevant definitions, the server needs to expose clear and safe contracts, and consequential actions need to return control to the person.
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
- Anthropic: Introducing advanced tool use
- Model Context Protocol Blog: The 2026-07-28 MCP Specification Release Candidate
- 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, and the official primary sources above on July 28, 2026. The public product count is 140 tools across 26 categories, with 50 official Workflow recipes. The 141-entry internal measurement includes record_conversation_trace. The static result is not a live MCP-client token bill, an accuracy benchmark, or evidence of a specific cost reduction. MCP 2026-07-28 is currently a release candidate; the stable specification remains 2025-11-25.
