MCP Token Usage: Measure Four Buckets per Outcome

MCP token usage should be measured per verified outcome , not per server, tool call, or chat. The useful total is the input consumed across every model call required to produce the requested result, split into four buckets: baseline instructions, exposed tool schemas, discovery history, and tool result payloads. Compare optimization candidates only after each one produces the same outcome receipt. That rule prevents two common mistakes. A provider session total cannot tell you whether schemas or results caused the growth. A tiny token count can look efficient even when the agent picked the wrong tool or omitted the deliverable. Count first, preserve the result contract, then change one surface at a time. Build a four bucket ledger before optimizing The MCP tools specification defines tools/list for discovery and gives every tool a name, description, and input schema. A client may transform that response before presenting tools to a model, so MCP itself does not “charge tokens.” The model request created by the client is what matters. For one task, record: Bucket What belongs in it Why it grows Baseline system instructions, user task, request wrapper repeated on each sampling call Schemas tool names, descriptions, input schemas, annotations the client exposes more tools, verbose descriptions, repeated exposure Discovery search matches, selected tool descriptions, prior discovery turns progressive disclosure adds round trips Results tool outputs retained in message history verbose payloads and repeated reattachment Sum each bucket across the complete path to one outcome: Keep provider cache reads, cache writes, output tokens, latency, and price in adjacent columns. Do not silently mix them into the four input buckets. They answer different questions. A cached schema may cost less on one provider while still occupying context and still needing freshness checks. Define the outcome receipt before the measurement. For the experiment below, the task was: return the current payment API error rate, observation time, and evidence source. A run passed only when all three fields existed: This is deliberately stricter than “the tool returned successfully.” A transport level success with no observation time could be stale. A percentage with no evidence source cannot be investigated. Compact output is useful only when it retains the fields needed for the next decision. Count the exact request, not a guessed text ratio Use the target provider’s counter with the same model, system prompt, messages, and tools you intend to send. Anthropic’s token counting documentation states that the endpoint accepts the same structured inputs as a message request, including tools. It also labels the result an estimate and advises counting against the intended model. A preflight request can look like this: Never put the key in the JSON fixture or a report. Save the returned input count with the model identifier, counter time, request hash, exposed tool count, call number, and outcome ID. Run the counter once for the baseline request, then again after each model/tool turn because discovery and result history change the next input. If your provider has no counter, use a pinned local tokenizer as a comparison proxy, not as a billing fact. Keep the serializer and tokenizer version fixed. The fixture for this article uses js tiktoken 1.0.21 with cl100k base ; that is reproducible across its three scenarios, but it is not a Claude tokenizer. The percentages below are evidence about the fixture’s relative shape, not a universal MCP saving. What the 40 tool fixture actually measured The inspectable artifact creates 40 synthetic operational tools. One tool returns the requested payment error rate evidence; the other 39 have realistic names, descriptions, and JSON schemas but are irrelevant to this task. It compares three paths: 1. expose all 40 schemas and retain a verbose result; 2. expose only the known tool and retain a compact result; 3. expose search tools , describe tools , and execute tool , then discover one schema and retain the compact result. Every path passed the same three field receipt. The measured proxy inputs were: Scenario Calls Baseline Schemas Discovery Results Total Saving : : : : : : : Static 40 tools, verbose result 2 110 8,768 0 625 9,503 baseline Selected tool, compact result 2 110 188 0 55 353 96.3% Dynamic discovery, compact result 4 220 572 309 55 1,156 87.8% The dominant observation is attribution, not the headline percentage: repeated schemas contributed 8,768 of 9,503 proxy tokens in the static path. Trimming the result alone would not repair that workload. Conversely, when the correct tool was already known, the one tool path beat dynamic discovery because discovery doubled the number of model calls and added 309 history tokens. The fixture and counter are small enough to inspect: Reproduce the structure with your real tool definitions, but replace the proxy with your provider’s counter before setting a cost or context window threshold. Also replace the synthetic success receipt with a deterministic check of your actual deliverable or external effect. These results agree with the direction of a larger Speakeasy dynamic toolset benchmark: progressive tool exposure can greatly reduce static schema input, but it requires more tool calls and can increase latency. Their percentages came from their toolsets, tasks, and model. They are not a promise for yours. Choose the control from the largest bucket Use the ledger to choose one intervention: If schemas dominate and the required tool is known from routing context, expose an allowlisted subset. If schemas dominate but the tool is not known, test dynamic search and description against retrieval miss cases. If results dominate, project only decision relevant fields and keep freshness, coverage, errors, and evidence references. If the baseline dominates, shorten repeated instructions or separate stable policy from task specific context. If discovery dominates, improve routing, reuse a safely scoped selection, or accept a larger static subset. Do not start with “install a token optimizer.” Start with the bucket and the task. A forty tool CRM surface may justify progressive discovery. A scheduled health check that always calls one known read only metric tool probably does not. For dynamic discovery, test failure as aggressively as savings. Include ambiguous user terms, near duplicate tool names, unavailable tools, permission loss, stale tool lists, and a query that should select no tool. Measure selection accuracy and P95 time to the verified outcome. The extra search step is worthwhile only when schema reduction exceeds its retrieval and latency cost. Result compaction needs its own boundary. Keep identifiers, units, observation time, coverage, error state, and an evidence reference whenever they affect the next action. Avoid full records, duplicated prose, unused metadata, and raw logs. If a compact result removes the reason an operator can trust or reproduce a verdict, it is data loss. Use a simple promotion gate: Set the targets from your workload rather than copying the fixture. Revert if outcome quality, tool selection, freshness, or verification regresses. “Fewer tokens” is not a recovery signal, and a completed MCP call is not proof that the intended work happened. Keep the health boundary explicit Token growth can indicate repeated schemas, oversized tool results, retries, or context accumulation. It can also be legitimate: a new tool becomes necessary, an investigation needs evidence, or the agent is waiting rather than looping. Interpret the ledger beside useful progress and the expected outcome. Sidewisp is currently in private preview. Its product direction includes time and budget efficiency as one agent health signal, but live token usage collection and optimization are planned; that capability is not shipped today. The practical step now is to keep your own per outcome ledger, preserve evidence, and test one MCP exposure change at a time. The decision is then concrete: use selected exposure for a stable known tool route, dynamic discovery for a large uncertain surface that passes retrieval tests, and result projection when payload history is the real cost. Publish the change only after the same outcome receipt still passes.