Research-backed calculator guide

MCP Tool Calling Cost: Price Tool Catalogs, Turns and Intermediate Results

Estimate MCP tool calling cost by separating catalog tokens, model turns, tool results, output tokens, and execution charges. Includes a worked example and practical controls.

What actually creates MCP tool calling cost?

MCP is a discovery and execution protocol. A client can connect to a server, retrieve its available tools, expose those tools to an agent, and invoke the selected tool. Microsoft’s Agent Framework documentation illustrates this sequence: connect to an MCP server, list its tools, convert them for the agent, and invoke them through the agent loop.^[5] The protocol does not make a single universal price. Your model provider, MCP server, transport, hosting, and workflow determine the bill.

Think of each model turn as a ledger row. The row should contain at least these components:

1. Catalog tokens. Tool names, descriptions, input schemas, and examples exposed to the model. Anthropic defines a client tool using fields such as name, description, and input_schema; those fields are part of the request’s tool payload.^[2]
2. Ordinary context. System instructions, the user message, relevant conversation history, retrieved context, and any application state sent on that turn.
3. Tool-call output. The model’s structured selection and arguments. This is output-token usage even though it may look like JSON rather than prose.
4. Tool results. The server’s returned text or structured data, which is often sent back as input on the next model request. Large results can cost more than the original tool schema.
5. Execution and platform charges. MCP hosting, gateway, database, search, or other service charges that are not model input/output tokens. Keep them as separate ledger columns rather than hiding them inside a token rate.

The most common accounting mistake is to count only the final assistant answer. The useful answer may be 200 tokens while the agent has already paid for a catalog on six turns and passed a 5,000-token document through the context. The final answer is not the cost basis.

A practical MCP cost formula

For a run with T model turns, define:

• D = catalog tokens exposed on each turn;
• C_t = ordinary context tokens on turn t;
• A_t = tool-call argument tokens on turn t;
• R_t = tool-result tokens returned into the next model request;
• O_t = model output tokens on turn t;
• p_in and p_out = the provider’s rates in dollars per 1 million input and output tokens.

A transparent estimate is:

input tokens = Σ(C_t + D + A_t + R_t)

output tokens = ΣO_t

model cost = input tokens ÷ 1,000,000 × p_in + output tokens ÷ 1,000,000 × p_out

Do not assume D is paid only once. Some systems cache prefixes, some do not, and cache write/read pricing can differ from ordinary input pricing. Record the provider’s reported usage fields and compare them with your ledger. Anthropic’s token-counting endpoint can estimate input tokens for requests containing client tools, but its documentation warns that counts are estimates and says requests using the MCP connector or other server tools are not accepted by that endpoint; actual usage is reported in the Messages API usage object.^[3] That is a reason to reconcile estimates against production responses, not a reason to omit MCP tokens.

Worked cost example

Suppose an internal support agent connects to several MCP servers. This is an illustrative estimate, not a vendor quote. Assume an input rate of $3.00 per 1 million tokens and an output rate of $15.00 per 1 million tokens. Replace both rates with the exact model and service-tier rates on your invoice.

The run has five model turns. Twenty available tools average 450 catalog tokens each, so D = 20 × 450 = 9,000 tokens per turn. Each turn also has 2,000 tokens of system, user, and conversation context. Three turns receive a 2,500-token tool result, and the model emits 700 output tokens per turn.

This example excludes MCP server compute, network egress, storage, logging, retries, prompt-cache effects, and provider-specific tool charges. It also assumes the 2,500-token results are each sent into a subsequent model request once. If a result is truncated, summarized outside the model, or kept inside a code-execution environment, the measured input total changes.

Now filter the catalog to five tools averaging the same 450 tokens. The catalog becomes 2,250 tokens per turn. Input becomes (2,000 + 2,250) × 5 + 7,500 = 28,750 tokens. Output remains 3,500 tokens. At the same illustrative rates, the model estimate is $0.08625 + $0.0525 = $0.13875 per run. The difference is $0.10125 per run, or about 42.2% in this constructed example. That percentage is not a promised saving; it is the result of the stated assumptions.

At 10,000 runs per month, the two scenarios would be approximately $2,400 and $1,387.50 in model charges before excluded costs. Use the AI API Invoice Reconciliation calculator to compare this modeled amount with provider usage exports once the workflow is live.

Catalog overhead versus intermediate-result overhead

A large catalog is a fixed shape repeated across turns. Intermediate results are variable. A request that returns a short status object may add little, while a document, database row set, or verbose API error can dominate the next request. Track both separately so the remediation matches the cause.

If catalog tokens dominate, first expose fewer outcome-shaped tools. A single track_order tool may replace a chain of user lookup, order lookup, and shipment lookup calls. The MCP server can perform deterministic API work internally and return the small result the model needs. This can reduce turns and intermediate context, but it may increase server-side implementation work and should be tested for error handling.

If result tokens dominate, return only the fields needed for the next decision. Prefer an identifier, summary, or bounded page over a full object. Apply filtering, aggregation, and redaction before the result reaches the model. Do not treat truncation as automatically safe: if the model needs a missing field, it may issue another call and erase the expected saving.

If both dominate, progressive disclosure is worth evaluating. Anthropic’s tool-use materials describe tool search for discovering and loading tools on demand, while the programmatic tool-calling documentation describes running multiple calls in code so intermediate results do not enter the model context between every call.^[4] Those patterns shift cost and complexity. Tool search adds a discovery step; code execution needs a secure runtime, limits, and monitoring. Benchmark the whole workflow rather than quoting a percentage from another system.

The AI agent budget guardrail and P95 calculator can help turn the mean estimate into a budget policy. Include a high-percentile run, not just an average, because one unusually large tool result or retry chain can dominate the monthly tail.

What to measure in production

Create one usage record per model request and attach a stable workflow or run ID. Record provider, model, service tier, input tokens, output tokens, cached input if reported, turn number, tools exposed, tools called, tool-result bytes or tokens, status, and retry count. Add separate MCP fields for server, tool name, execution duration, response size, and server-side charge.

Then calculate four ratios:

• Catalog share = catalog input tokens ÷ total input tokens.
• Result share = tool-result input tokens ÷ total input tokens.
• Cost per successful run = all run charges ÷ successful runs, including failed attempts if they consumed paid model calls.
• Tool efficiency = successful business outcomes ÷ tool calls, with your outcome definition stated.

Do not infer token counts from character length when the provider exposes usage data. Character-to-token multipliers vary by tokenizer, language, JSON shape, and model version. Use a tokenizer or provider count endpoint for preflight estimates, then reconcile with billed usage. Keep currency, region, and rate-card date in the record. The official token-counting guidance describes counts as estimates and notes that different active model families can tokenize the same text differently.^[3]

Finally, compare cost against latency and correctness. Removing a tool can lower input tokens but cause a longer chain of calls. Compressing a schema can save tokens but remove selection-critical detail. A cheaper run that returns the wrong record is not a successful optimization.

FAQ

Is MCP itself a paid API?

MCP is a protocol, not one universal billing plan. You may pay a model provider for input and output tokens, an MCP host or gateway for infrastructure, and the upstream service for its own requests. The protocol can add work without adding a distinct MCP line item, so reconcile the model usage and server invoices separately.

Are MCP tool definitions counted on every turn?

Treat them as per-turn input unless your provider explicitly documents caching or another reuse mechanism. If the client sends the catalog on five model requests, start with five ledger entries. Then replace the estimate with provider-reported usage and cache metrics. A persistent connection or a one-time tools/list call does not by itself prove that the model receives or pays for the definitions only once.

How many MCP tools are too many?

There is no universal threshold. The practical limit depends on schema verbosity, model context, selection accuracy, workflow turns, and rate card. Measure catalog share and tool-selection errors. Start by exposing the smallest useful set for each agent, then test filtering or on-demand discovery when the catalog is a material share of input tokens.

Do tool results cost input or output tokens?

The model’s structured tool-call message is output from the model. The server’s result is usually included in the next model request, so it is input to that next request. Record the direction that your provider’s usage object assigns. Never count a result as “free” simply because it was produced by your own server.

Does tool filtering always reduce total cost?

No. Filtering can reduce catalog tokens and improve selection, but a missing tool may cause extra discovery calls or retries. Compare complete successful runs: all model requests, all tool results, latency, and outcome quality. The worked example above shows only the arithmetic under fixed-turn assumptions.

Should I use a model’s token-counting endpoint for MCP?

Use it where supported for preflight estimates, but check the endpoint’s scope. Anthropic documents support for client tools and says requests containing its MCP connector or other server tools return an error; the API usage object is the production measurement source in those cases.^[3] Other providers may expose different counters. Always reconcile estimates to the actual request response and invoice.