MCP server costs: tokens, hosting and tool calls

Updated 22 October 2026 · first published 4 July 2026

An MCP server connects an AI application to tools and data. Its total cost can include server hosting, paid services behind the tools, and model tokens used to select tools and read their results. Connecting a server does not create a fixed token charge. What the host sends to the model, how many steps it runs, and how the provider bills caching determine the model portion.

What is an MCP server?

The Model Context Protocol architecture separates the host application, its MCP clients, and MCP servers. A server exposes capabilities such as a database query or document search. The host manages the model interaction. A client discovers tools with tools/list and invokes a selected tool with tools/call.

A local server can run as a subprocess using standard input/output. A remote server can run as a separate HTTP service. Neither arrangement determines which model you use or how many tokens it consumes.

What do you actually pay for?

A locally installed open-source server can have no subscription fee while still consuming machine resources and paid API calls. A hosted server may charge a subscription or per request. Count bundled services once: if a managed fee includes search or hosting, do not add the same charge again.

How do MCP tools increase token usage?

• Tool definitions: names, descriptions and schemas add input when the host includes them in a model request.
• Tool selection: the model may generate tool names and arguments as output.
• Tool results: returned data adds input when the host passes it to the model, and can remain in later context.
• Extra steps: retries, planning and follow-up model calls can repeat existing context and generate more output.

MCP discovery and model inference are different operations. The protocol does not require every connected tool definition to be sent on every model turn. A host can select a subset or discover tools on demand. Parallel tool execution can also share a model turn; one tools/call is not necessarily one additional model API request.

Prompt caching changes the price of repeated input, not the amount of useful work completed. Use the provider's actual cache fields rather than assuming all repeated tokens are cache hits. Our tool-definition overhead guide focuses on reducing the schemas your application exposes.

A worked MCP token-cost example

Illustrative assumptions, not a benchmark or a provider quote: a host includes 4,000 tool-definition tokens on each of six model calls. Those calls also consume 6,000 additional input tokens in total from tool results, including any repeated results. Tool names and arguments add 1,000 output tokens. Assume uncached input costs $2 per million tokens and output costs $10 per million.

At 10,000 workflows, those components cost $700. Reducing the definitions from 4,000 to 1,000 tokens on each call saves $0.036 per workflow, or $360 over that volume, if the other counts stay unchanged. Hosting, paid tool services, base prompts, answer tokens and any extra reasoning are excluded.

This estimates identifiable token components. It does not prove the workflow is $0.070 more expensive than a tool-free alternative: tools may improve completion, reduce other context, or avoid retries. Test both designs on the same tasks before claiming savings.

How should you measure MCP overhead?

1. Assign one workflow ID to the entire task, with child IDs for model attempts and tool executions.
2. Record provider, model, service tier, input/output usage, cache breakdown, latency and outcome for each model attempt.
3. Record server, tool, duration, retry attempt and downstream charge for each tool execution. Keep infrastructure allocation separate from per-call fees.
4. Compare matched tasks using the full tool catalogue and a selected subset. Hold model settings constant; report cache state and completion quality.
5. Sum all billed attempts and divide by successful tasks. Reconcile provider estimates against invoices before reporting financial savings.

Counting a tool result as input is useful attribution, but its tokens are already inside the model's input total. Do not add the result-token estimate to that total again. Similarly, a server that invokes another model needs a child charge only if that usage is not already captured elsewhere in your ledger.

Which cost controls should you try first?

• Expose relevant tools: reduce the active catalogue and check that tool selection still works.
• Return bounded results: project required fields, paginate long lists, and let the agent fetch detail when needed.
• Reuse stable context: measure cache reads and writes under your provider's rules.
• Bound execution: cap tool attempts, workflow steps and total spend. Reserve budget before launching parallel work.
• Cache tool results selectively: reuse safe reads with an explicit freshness policy; do not replay writes or mix tenant data.

The practical agent workflow guide combines these controls into a workflow with configuration, logging and a worked cost ledger.

Sources and scope

Technical references checked 22 October 2026: official MCP architecture, MCP transports, and OpenAI prompt caching. The dollar example uses explicitly assumed rates so you can substitute your own.

Related

• Control tool-definition overhead
• Attribute agent spend
• Build an observable agent workflow

Want this applied to your own LLM spend? Bring your provider bills and a sample of tool-heavy workflows. Book a free audit →

Back to research