Why MCP Tool Definitions Inflate Token Costs in Multi-Step Agents, and How to Limit Them

How tool definitions accumulate across agent steps

An MCP server advertises its tools as structured definitions: a name, a natural-language description and a JSON schema describing each input parameter. An agent host collects these from every connected server and passes them to the model alongside the system prompt and conversation. The model needs this text to decide which tool to call and how to format the arguments.

Model APIs are generally stateless, so the host sends the full context on each call. In a multi-step agent, every reasoning step or tool call is another model call. The tool definitions are included each time, together with the growing conversation history and the results returned by earlier tool calls. Input tokens per run therefore scale roughly with tool-definition size multiplied by the number of steps, plus the history that accumulates on top.

The practical consequence is that adding a server increases the cost of every step in every run, including runs that never use that server. The overhead is a standing charge on the context, not a charge per tool invocation.

Main contributors and what they affect

Four factors drive the footprint. The first is tool count: more connected servers mean more definitions. The second is schema verbosity: deeply nested parameters, long enumerations and repeated optional fields add tokens quickly. The third is description length: descriptions written for human documentation often carry examples and caveats the model does not need on every call. The fourth is overlap: several tools that do similar things inflate the list and make selection harder.

The effects fall in three areas. Context limits: definitions consume window space that would otherwise hold history and tool results, so long runs reach the limit sooner. Latency: larger inputs generally take longer to process on each call, and the cost compounds over many steps. Tool-selection accuracy: a long list of similar tools gives the model more chances to pick the wrong one or to mis-fill arguments. These effects should be confirmed in your own environment rather than assumed, which is why measurement comes first.

A prioritized sequence of mitigations

Sequence the work from lowest risk and effort to highest. Earlier steps are mostly configuration and editing. Later steps change how the agent discovers tools and carry more operational cost.

• 1. Baseline the footprint: Count the tokens of the serialized tool list per request and per agent run, using your model provider's usage metrics or a tokenizer. Record tokens per step so you can see the compounding effect and compare each later change against it.
• 2. Scope tool sets per agent or task: Expose only the servers and tools a given agent or task needs. This usually gives the largest reduction for the least engineering effort, and it also narrows what the agent can reach.
• 3. Trim schemas and descriptions: Remove redundant parameters, shorten descriptions to what the model needs to choose and call the tool, and drop examples that do not change behavior. Re-test argument accuracy after each edit.
• 4. Consolidate overlapping tools: Merge tools that serve the same purpose or differ only by a parameter. Fewer, clearly distinct tools reduce both tokens and selection errors.
• 5. Load tools on demand: Give the model a compact index or a search tool, and load full definitions only for tools it selects. This helps most with large catalogs but adds a lookup step and new failure modes.
• 6. Cache stable prefixes: Where your model provider supports prefix caching, keep the system prompt and tool list stable and ordered first so repeated calls can reuse them. Behavior and pricing vary by provider, so verify the effect with your baseline.

Trade-offs: over-pruning and the cost of dynamic loading

Every reduction technique trades tokens against something else. Aggressive scoping can remove a tool the agent legitimately needs, which shows up as failed tasks or workarounds rather than as an obvious error. Trimming descriptions too far can leave the model unable to distinguish similar tools. Evaluate each change against task success and argument accuracy, not only token counts.

Dynamic approaches add moving parts. On-demand loading and tool search introduce an extra step, so latency can rise for tasks that need tools from the catalog. The retrieval mechanism itself can miss the right tool. Changing the tool list during a run can also undermine prefix caching, since caching generally depends on an unchanged prefix. Static scoping and trimming are easier to reason about and to test, so most teams should exhaust them before adding dynamic selection.

Finally, keep the two meanings of token separate. Context tokens measure model input. Authentication tokens are credentials. Reducing the first says nothing about the safety of the second.

Tool scoping is a least-privilege decision, not only an efficiency measure

The set of tools an agent can see and call is a policy decision. Tool restrictions are recognized as one category of agent system-level control, alongside prompt engineering and continuous monitoring. Agents given broad access may use unexpected tools or data, which is a reason to narrow scope even where token cost is not a concern.

Two mechanisms should be kept distinct. Discovery determines which tools appear in the model context. Permission determines which calls are allowed to execute. Hiding a tool reduces what the model is likely to attempt, but it does not replace verification at the point of the call. NIST guidance on agent identity favors just-in-time, time-bounded and audience-specific access grants, and continuous runtime verification of each tool invocation, so that an agent holding a valid credential can still be interrupted if it is manipulated mid-task. A practical alignment is to derive the per-task tool set and the per-task credential scope from the same definition.

Enforcement of this kind is not a token-reduction technique. Trussed enforces policy in the execution path for models, agents, tools and MCP servers: allow, redact, block, rate limit, or escalate a tool call for human approval. That enforcement is applied at runtime, not reviewed after the fact, and it generates audit-ready evidence of what an agent was allowed to do and did. It operates alongside the context controls above and does not change how many definition tokens are sent.