Direct answer
Price the model turn around an MCP call—not the server itself
An MCP tool call can bring definitions, arguments, results, and repair attempts into model context. Multiply the number of calls by a consistently measured turn-attributed token average, then apply a model rate. Keep repeated schema/context and error-associated work visible as diagnostics rather than pretending they are separate vendor charges.
Estimate MCP-calling turn cost
Enter observations from one consistent period. Every result stays in this browser; the worksheet does not upload these inputs.
Scenario output
Attributed tokens
6,640,000
8,300 tokens per MCP-calling turn × 800 calls
API-equivalent model cost
$19.92
At your blended worksheet rate of $3.00 per million tokens; estimate, not an invoice.
Repeated schema / context tax
1,440,000
$4.32 of the estimate if this context is genuinely additional and repeated.
Error-associated tokens
498,000
60 rounded error calls · $1.49 associated cost, not automatically recoverable waste.
Dollar results are API-equivalent estimates based entirely on your inputs.
Transparent math
How MCP token-cost attribution works
Start with one observation window and one attribution rule. The calculator adds optional repeated schema/context tokens to the average surrounding-turn workload, multiplies that total by calls, and prices the resulting model tokens. Set the optional field to zero when your observed average already contains that context.
Worked example
Worked example: inspect a context-heavy integration
These numbers explain the default worksheet; they are illustrative and do not describe a provider, MCP server, or representative benchmark.
| Step | Assumption | Result |
|---|---|---|
| Turn workload | 6,500 + 1,800 tokens/call | 8,300 tokens/call |
| Attributed volume | 800 calls × 8,300 | 6,640,000 tokens |
| API-equivalent cost | 6.64M × $3/M | $19.92 |
| Error association | 60 rounded error calls × 8,300 | 498,000 tokens · $1.49 |
| Investigation signal | 1.44M tokens came from the optional repeated-context assumption; verify it before optimizing. | |
Optimization playbook
Reduce MCP-associated tokens without breaking the tool contract
Optimize only after separating high call volume, large context, and high error rate. Each suggests a different intervention, and the best check is a before/after transcript sample using the same tasks.
Trim definitions before results
Inspect tool descriptions and JSON schemas that are present on every eligible turn. Remove redundant prose, unused properties, and overlapping tools only after confirming the model still selects and calls the right capability.
Expose the smallest relevant tool set
Scope servers and tools to the task instead of loading an entire catalog into every agent session. Measure selection accuracy as well as tokens: a smaller menu is only a win when it does not hide the needed action.
Repair recurring call errors
Group failures by exact tool and cause—authentication, permission, argument validation, timeout, or upstream response. Fix deterministic failures before adding blind retries that can repeat both token usage and side effects.
Shape large tool responses
Return only fields, rows, and detail needed for the next decision. Pagination, filters, summaries, and stable resource references can reduce model-visible context while leaving the underlying server data intact.
First-party reference
Compare the worksheet with observed MCP activity
The live research page groups exact names shaped like mcp__server__tool into server observations and shows calls, attributed turn tokens, and observed errors. Its opt-in public cohort is a reference—not an industry-wide pricing benchmark.
Interpretation
Frequently asked questions
Does an MCP server itself consume model tokens?
Not in the way a model API does. MCP transports tool definitions, arguments, and results; a model may read or generate some of that material in its surrounding turn. This calculator estimates that model-side token workload. It does not price the server's CPU time, network traffic, upstream API, database, or hosting.
What does turn-attributed tokens per call mean?
It is a reporting convention: tokens from a model turn containing tool activity are associated with the call, and a multi-tool turn may divide them across calls. Attribution makes workloads comparable, but it cannot prove that one tool caused every token in the turn. Use the same convention across scenarios.
Can I add developer counts from every MCP tool?
No. One developer can call several tools, so summing distinct-developer counts across tool rows double-counts people. Calls, tokens, and errors can be additive when rows are mutually defined, but a server-level developer total requires a union of developer identities that the public aggregate does not expose.
How should I enter model price when input and output rates differ?
Use a blended dollars-per-million rate derived from the same observed workload, or calculate input and output separately in the general LLM cost calculator. Document the rate and date. A single blended rate is convenient for sensitivity analysis, not a substitute for provider billing buckets.
Is every error-associated token avoidable waste?
No. A failed call can still involve necessary reasoning, validation, or a useful diagnostic response. The result is the token volume associated with error calls under an average-turn assumption. Review exact errors and retries before calling any portion preventable.
Why can the estimate differ from my bill?
The worksheet does not know your exact input/output mix, cache rates, batch discounts, subscription allowances, routing, retries, free tiers, taxes, negotiated prices, or upstream MCP service fees. It is a transparent API-equivalent estimate, not an invoice.
Sources
- whoburnedmore public insights API
Aggregated model, agent, trend, skill, and tool-call totals from participating developers.
- Data collection and privacy methodology
Explains what the CLI aggregates, what it does not collect, and the limits of the public cohort.