How to Cut MCP Token Usage: Measure the Whole Task

To reduce MCP token usage, measure what your client actually sends to the model, then reduce unnecessary tool definitions, oversized results, or repeated discovery. Compare complete tasks, including extra model calls. A smaller initial tool list can help, but it is not automatically a cheaper or faster workflow.

MCP does not require every host to put every connected server's full catalog into every model request. The host's loading and orchestration strategy determines that behavior. Start by identifying whether your client loads tools eagerly, filters them, or discovers them on demand. This guide gives you a measurement worksheet and a deliberately simplified example whose assumptions you can replace with your own observations.

Separate protocol traffic from model input

A tools/list response travels between an MCP client and server. A model request is a separate payload assembled by the host. The MCP 2026-07-28 tools specification describes discovery, tool schemas and invocation; it does not mandate one universal model-context loading policy. Count the serialized definitions actually presented to your chosen model rather than treating the size of a catalog response as an exact billable amount.

The current MCP architecture is stateless, with version and capabilities carried per request. Older clients may implement earlier lifecycle revisions. Neither an old initialization exchange nor current per-request metadata establishes that a model received the entire catalog. Inspect the host behavior separately.

There are several potentially large inputs: tool names and descriptions, input schemas, discovery summaries, returned content, conversation history, and instructions. Tool-call arguments and the assistant's reasoning or answer also contribute to usage under the provider's accounting rules. A definition-only estimate is useful for one component, not the total task cost.

Build a measurement record before changing configuration

Choose a representative set of tasks with clear success conditions. Include a task requiring one familiar tool, a task requiring an unfamiliar connector, and a task that crosses two systems. Use synthetic data where possible. Keep the model, client version, task text, permissions, and available catalog fixed within each comparison.

Use provider-reported usage for the complete task where available. For example, Anthropic's token-counting documentation supports counting structured client-tool inputs and explains that the result is an estimate. It also documents unsupported inputs, including its MCP connector, for which actual Messages API usage is the relevant observation. Do not assume one counter accepts every provider-native MCP request shape.

If the client hides the actual model payload, label a local schema-token calculation as an estimate. A “servers connected” versus “servers disconnected” comparison can also change instructions, routing and cache state. Treat the difference as an observed configuration effect, not a perfectly isolated measurement of MCP protocol overhead.

A transparent example, including discovery overhead

The following numbers are fictional arithmetic inputs, not measured MCP Beast results or typical server sizes. Assume an eager-loading workflow presents 60 tool definitions averaging 200 tokens each: 12,000 definition tokens per model call. It completes a task in four model calls, so that component contributes 48,000 input tokens across the task.

For a selective workflow, assume six model calls because discovery adds two steps. The model sees 800 tokens of dispatcher definitions plus a 600-token connector summary on each call. Assume discovery responses, selected schemas and their repeated appearances in later history contribute another 7,200 input tokens across the task.

Eager definition component:
60 tools × 200 tokens × 4 model calls = 48,000 tokens

Selective routing component:
(800 dispatcher + 600 connector summary) × 6 calls = 8,400 tokens
Discovery/schema/history component across calls = 7,200 tokens
Selective subtotal = 8,400 + 7,200 = 15,600 tokens

Difference in the compared components = 32,400 tokens

That difference is about the selected components only. It excludes shared instructions, task messages, ordinary tool results, outputs and other provider overhead. The additional model calls may repeat those excluded inputs. Cache pricing can also change the financial comparison. To claim a whole-task improvement, add every call's usage and check successful completion in both configurations.

Use the MCP context budget calculator to compare one model call’s catalog components with your own measured counts, including the growing server roster. Keep the whole-task worksheet alongside it: this component arithmetic does not replace complete usage and cache measurements.

The example is sensitive to how many definitions a task needs. If discovery repeatedly fetches broad result sets, or the task ultimately uses most of the catalog, its advantage can shrink. For a single small tool used repeatedly, the direct configuration may be simpler. Use the arithmetic to identify what to measure, not to choose a deployment based on an invented savings percentage.

Optimize the largest observed component

If definitions dominate, first remove accidental duplicates and irrelevant integrations from that client. Maintain the intended scope in your server inventory, so another team member can understand why the configuration differs from theirs. Do not remove a rarely used recovery capability without considering how operators will obtain it when needed.

If discovery dominates, examine result limits, repeated queries, and whether useful schema information is being fetched again. Preserve enough connector context for the agent to know which capabilities exist. An extremely short roster that hides the relevant server can create extra searches or a false conclusion that the task is impossible.

If tool results dominate, prefer supported pagination, narrower fields, or a focused query over retrieving an entire collection. A summary may be appropriate for some tasks, but it can omit evidence needed for another. Test the actual outcome after reducing result size rather than assuming fewer tokens preserve the same information.

If descriptions dominate, remove redundant prose while retaining disambiguation and input constraints. Similar tool names need enough context to identify the correct system. Evaluate selection errors and correction attempts after editing descriptions; shorter text can increase total usage when it causes avoidable calls.

Filtering visibility is also distinct from authorization. Enforce access at the invocation and downstream boundaries even if a tool is absent from model context. The access-control guide explains why hiding a capability is not sufficient evidence that it cannot be called.

Treat caching as a separate measurement

Anthropic's prompt-caching documentation distinguishes uncached input, cache creation, and cache reads. Its total input accounting adds those three fields. Cache reuse depends on matching eligible prompt content; the provider documents the relevant lifetime and invalidation conditions.

Track a first run and repeat runs separately. Report cache conditions alongside the result so a cold selective workflow is not casually compared with a warm eager one. A reduction in uncached input alone is not proof that less context was processed. Likewise, a larger cached input can have a different billed cost from a smaller uncached request.

Use current rates for the actual model and platform when converting usage to money. Keep input, output, cache creation, cache reads, and any separately billed tool operations in distinct rows. This article intentionally provides no universal dollar estimate because a token count without those assumptions is incomplete.

Evaluate routing with successful tasks

MCP Beast's router uses discovery, selected schema retrieval, and invocation. Its connector summaries also help agents identify available capabilities. That design provides a concrete selective-discovery path to evaluate; it does not make all catalog-related context constant or guarantee fewer total tokens for every workload.

Compare the same tasks through your existing client setup and the proposed route. Include wrong-tool selection, missing-tool recovery, expired authorization and oversized results in the evaluation. Record whether the task completed, how many correction calls it required, and what evidence explains the usage difference. Use the gateway buyer guide to keep cost, latency, access control and operational recovery in the same decision.

Copy this blank ledger for each run and add a row for every model call, including discovery and correction calls. Record the accounting source and distinguish provider-reported usage from local component estimates. Blank cells below are unmeasured, not zero; write unknown when the client cannot expose a field.

Use the provider's field definitions to compute each call's total input exactly once. If its input total already includes cache components, keep those components as a breakdown rather than adding them again. If it reports mutually exclusive uncached/read/write categories instead, record that basis and sum those categories once. Local estimates of definitions or results explain components; do not add them to a complete provider-reported total that already includes them.

Then complete one paired-run decision row for the same task. Sum usage across all calls in each run, including failed attempts; retain input and output separately and compare matching cache categories. Measure task elapsed time from task start to its defined end, rather than assuming call durations sum to elapsed time.

Record model/client, catalog/permissions, task or cache-state differences as comparability exceptions. A missing success result or incomplete usage ledger leaves the whole-task comparison unresolved. The earlier four-versus-six-call illustration supplies neither complete task totals nor dollar costs for these rows.

A useful report lets a teammate repeat the comparison from the linked configuration and workload records without guessing the cache state or accounting method. Recheck when a meaningful model, client, tool or workload change invalidates that evidence.

Frequently Asked Questions

Does every MCP server load all its tools into model context?+

No. MCP defines discovery and invocation, while the host decides how available tools reach the model. Clients may load eagerly, filter definitions or discover selected tools on demand.

How should I measure MCP token usage?+

Record usage across every model call in a representative completed task. Include definitions, discovery, schemas, results, output and cache accounting, and keep the model, client, permissions and catalog consistent across comparisons.

Does prompt caching remove tool definitions from context?+

Caching changes how eligible repeated input is processed and billed; it is not evidence that the definitions were removed. Inspect total input and cache categories separately using the provider's accounting rules.

Will selective discovery always reduce total cost?+

No. It can reduce definition loading, but adds discovery work and may add model calls. Compare whole-task usage, current pricing, latency and successful completion for the workload you intend to run.

Start with one recurring task and capture its complete usage record. Then change one loading or result-size decision and compare the outcome before expanding the experiment.