Compare the catalog components of an eager and a routed setup for one model call. Supply your own measured token counts and see the arithmetic, including routing overhead.
Enter measured counts for the same model and client setup. Only these catalog components are compared. Inputs stay in this tab’s memory; the calculator does not send, log, or save them. No account is needed.
Eager catalog tokens = servers × tools per server × average schema tokens.
Routed component tokens = servers × roster tokens per server + dispatcher tokens + discovery tokens + selected tools × average schema tokens.
The roster grows with the server count. Dispatcher and discovery are separate inputs, and selected schemas use the same average as the eager comparison. Keep these categories disjoint: text counted in the roster must not also be included in discovery. The available tool count is servers × tools per server. These formulas model two scenarios you choose; they do not assert that every MCP host sends every discovered schema to its model.
The difference is eager minus routed. A positive value means fewer tokens in the modeled routed component, while a negative value means more. The percentage uses the eager total as its baseline and is rounded to two decimal places. A zero eager total has no percentage comparison. Limits apply independently to each alternative total, not to the sum of the alternatives.
MCP tools/list carries tool definitions between a server and a client. A host decides what reaches a model request. A response’s JSON byte length is not its model token count, and a cached catalog does not by itself establish a provider prompt-cache hit.
Use the same model, tokenizer, client version, catalog, permissions, and request shape for both sets of inputs. Measure definitions including names and descriptions, the server roster, dispatcher definitions, and retained discovery text. If server catalogs differ substantially, the whole-number tools-per-server and average-schema inputs are approximations; document those assumptions alongside your measurements.
Anthropic’s token-counting documentation supports structured client-tool inputs but describes its count as an estimate. The endpoint does not support the MCP connector; use actual Messages API usage for that request path. This browser tool calls no tokenizer or provider endpoint and cannot infer counts from a server URL.
The result omits user and system messages, prior turns, returned tool results, output tokens, and unrelated tools. It does not multiply by an assumed number of model calls, price tokens, forecast savings, or model cache reads and writes. A routed task can need more calls, and each call can retain different discovery text.
Record complete provider usage across the same completed task, cache behavior, latency, and answer quality before drawing a conclusion. Recalculate individual calls when their contents change. A smaller catalog component alone does not show whether the task fits a model’s context window or costs less.
The example uses 10 servers, 20 tools per server, 200 tokens per definition, 30 roster tokens per server, 500 dispatcher tokens, 800 discovery tokens, and 4 selected tools. That gives 40,000 eager tokens and 2,400 routed component tokens: 300 + 500 + 800 + 800. The difference is 37,600 tokens, or 94% of this example’s eager component. These fictional numbers are an arithmetic demonstration, not an MCP Beast benchmark or a promised reduction.
Keep the same 200 available definitions and 200-token average, but select more tools. Fixed routing overhead in this fictional comparison is 300 + 500 + 800 = 1,600 tokens. The break-even point shows when omitted definitions no longer offset that overhead.
| Selected of 200 tools | Omitted tools | Eager tokens | Routed tokens | Decision signal |
|---|---|---|---|---|
| 192 | 8 | 40,000 | 1,600 + 38,400 = 40,000 | Equality: no reduction in this component. |
| 193 | 7 | 40,000 | 1,600 + 38,600 = 40,200 | Loss: the routed component uses 200 more tokens. |
For a reduction, routing overhead must be less than omitted definitions × average definition tokens. This assumes selected and omitted definitions share the same average and compares only the catalog components of one call. Equality or a loss is useful evidence for deciding whether selective loading helps this request; measure complete tasks before drawing a cost or performance conclusion.
All inputs start blank. Enter zero deliberately for an absent component. Fields accept at most seven decimal characters and values up to 1,000,000; each scenario is capped at 100,000,000 tokens. Invalid values, excess selected tools, or unsafe arithmetic produce an error with no partial result. Editing an input clears the prior result so it cannot describe stale values.
No. It performs arithmetic on counts you provide. Measure model-visible tool definitions and routing text with your target model and client. JSON bytes from tools/list are not model token counts.
No. The comparison covers selected catalog components in one model call. Extra calls, messages, discovery history, results, caching, and provider billing can change the whole-task outcome. Measure complete usage and task quality separately.
The calculator shows the higher routed total and a negative eager-minus-routed difference. It does not clamp the difference to zero. When the eager baseline is zero, the percentage is N/A.
Each field must be a plain decimal whole number from 0 to 1,000,000. Blank fields are not zero. Selected tools cannot exceed servers multiplied by tools per server. Each scenario total must be at most 100,000,000 tokens; excessive or unsafe arithmetic is rejected without a partial comparison.
The calculator keeps counts and results in this tab's memory. It does not send them to analytics or another service, log them, store them, or add them to a share URL. Clear all removes the current inputs and result; reloading starts blank. The optional example uses fictional counts.