← All guides · MCP in practice

MCP Server Cost Optimization: Toolset Size, Caching Hints, and Fan-Out

Part 8 of MCP in practice · 1,498 words · published 2026-08-15 · updated 2026-08-15 · Markdown variant

How the token cost of an MCP server's tool list, the 2026-07-28 spec's ttlMs/cacheScope caching hints, fan-out from callers you do not control, and per-tool-name cost visibility each shape what a production MCP server actually costs to run.

Part of the MCP Server in Production: How to Build, Ship and Run One guide.

The pillar's cost section names three levers in one paragraph each — keep the toolset small, exploit ttlMs/cacheScope, watch fan-out — and points to agent cost and latency optimization for the underlying compounding model. This article goes deeper on exactly those three, plus a fourth angle the pillar does not cover at all: attributing cost to a specific tool rather than to a server-wide total.

How much does a large tool list actually cost, in tokens?

A tool list costs tokens every time it is fetched and placed into an agent's context, and that cost scales with how many tools are registered, not with how many of them ever get called. The compounding-cost model behind this site's cost guidance states it generally: Cost ≈ tokens_per_call × price_per_token × N, where N is the number of calls in a trajectory (agent cost and latency optimization). Applied to an MCP server's tool list specifically, the relevant substitution is:

• Let k = the number of tools registered on the server.
• Let t = the average number of tokens a single tool definition costs to describe (name, description, input schema).
• The token cost of the list alone, per fetch, is approximately k × t.
• If that list gets re-fetched and re-injected N times across a session or a fleet of sessions, the standing token tax is (k × t) × price_per_token × N — the same shape as the general formula, with the tool list substituted for a single call's payload.

Holding t, price_per_token, and N constant, a server exposing 50 tools instead of 5 carries roughly ten times the standing token tax per fetch that the 5-tool server does — an illustrative ratio, not a fixed number, since actual descriptions vary in length and some clients cache the list rather than refetching it every time (the next section covers exactly when that caching kicks in). The practical implication is the one the pillar already states as a rule — keep the toolset small — but the mechanism is worth seeing explicitly: it is not an abstract "audit surface" argument, it is a line item that scales linearly with k on every fetch that is not served from cache.

What do ttlMs and cacheScope actually change on the wire?

The ttlMs/cacheScope parameters, added to list and resource results in the 2026-07-28 MCP spec revision, give a server "an explicit, server-declared basis for client-side caching" (MCP goes stateless) — a signal a client can act on, not a caching layer the protocol builds for you. What changes with the hint set versus unset is a difference in default behavior, not a difference in what data is returned:

• Without the hint set, a client has no server-declared basis to assume a previous tools/list result is still valid, so the conservative default is to re-fetch it — paying the k × t token cost from the previous section again on every session or reconnection, even if the tool catalog has not actually changed.
• With ttlMs/cacheScope set, a compliant client may skip that re-fetch and reuse the previously fetched list for the declared duration and scope, which is what actually removes the repeated token cost rather than just moving it around.

This article's own reasoned caution, not a documented spec warning: setting a TTL longer than how often the underlying tool catalog genuinely changes risks a client acting on a stale list. A server whose available tools vary by user tier, by feature flag, or by session state — rather than staying fixed for every caller — should set a short TTL or a narrow cacheScope deliberately, because a client that skips a re-fetch it should have made will act on tool definitions that no longer describe what the server actually does. Treat the caching hint as a trade a server operator makes explicitly, not a default to maximize blindly for token savings.

Fan-out cost, from the server operator's side

Fan-out raises an MCP server's cost in a way the server operator cannot fix by changing anything about their own code, because the fan-out decision belongs entirely to whoever operates the calling agent. The pillar's fan-out bullet is written from the calling side: "if you are also the one operating the calling agent, the fix is architectural — fewer sub-agents, or a shared cache in front of your server." That fix is unavailable to a server operator who is not also the caller.

The underlying arithmetic is the same one that drives cost on the calling side — "a pipeline that spawns 5 sub-agents each making 10 calls multiplies spend by 50× relative to a single-agent 1-call solution" (agent cost and latency optimization) — but from a server's vantage point that multiplication shows up as aggregate request volume with no single visible cause. One integrator's badly architected fan-out and five separate integrators each making a handful of calls can produce the same request-rate spike on the server side; from inside the server, both look identical: more calls, no way to tell from volume alone whether it is one caller's runaway fan-out or organic growth across many callers.

What a server operator can actually do, since the calling side's architecture is out of reach:

• Per-key or per-client rate limiting, so one caller's fan-out is capped without penalizing every other caller.
• Coarser-grained tools that let a caller accomplish in one call what previously took several, which reduces the call count a given task generates regardless of how many sub-agents dispatch it.
• Usage quotas tied to identity, where the server has an identity to attach a quota to — which is itself a real constraint: a server with no per-key tracking has no lever here at all, only the blunt option of rate-limiting by IP or capping total throughput server-wide.

Track cost per tool name, not just per server

Aggregating token cost by tool name, the same way MCP server observability with OpenTelemetry already recommends aggregating latency and error rate by tool name, catches one expensive tool that a server-wide average would hide. That sub establishes per-tool-name p50/p95 latency and per-tool-name error rate as metrics distinct from per-call span logging, for the same structural reason cost hides too: any one tool's numbers get folded into an overall figure that a healthy majority of calls keeps looking fine, so the single outlier only shows up once it has already grown large enough to move that overall figure on its own.

The same logic applies directly to cost: a tool that returns a large payload, or one whose handler makes several model calls internally rather than a single deterministic lookup, can account for a disproportionate share of total token spend while the server's overall average still looks unremarkable. Aggregating cost by tool name surfaces that tool immediately instead of waiting for it to move the whole server's number. This reuses the same category of usage-tracking span attributes sub 6 already covers for latency and error rate — the addition here is grouping by tool name on the cost dimension specifically, not a new instrumentation mechanism.

Per-tool cost visibility also matters independently of whether a server can attribute cost to a specific caller. ChangeGamer's own /mcp endpoint is unauthenticated as of August 2026, gated only by a single api_key argument check with no per-key rate-limiting layer on top of it (issuing API keys to AI agents) — which means it has no built-in way to attribute cost to a specific caller. It can still attribute cost to a specific tool, because that grouping depends only on which tool a call invoked, not on who called it. A server without caller-level attribution loses the fan-out mitigation the previous section describes, but per-tool cost tracking remains available regardless, which makes it worth building even on a server that cannot yet identify its callers individually.

Where this leaves you

Treat a large tool list as a standing, session-repeated token cost that scales with how many tools are registered, not with how many actually get called, and cut the list before reaching for any other lever. Set ttlMs/cacheScope deliberately once the 2026-07-28 spec revision makes them available, short where the catalog genuinely varies by user or session and longer only where it demonstrably does not. Expect fan-out to show up as aggregate load with no single visible cause when the calling side's architecture is outside your control, and reach for per-key rate limits, coarser tools, or quotas instead of a fix that only works if you also operate the caller. And build cost aggregation by tool name alongside the per-tool latency and error-rate dashboards MCP server observability with OpenTelemetry already recommends, because a server-wide cost average hides exactly the kind of single expensive tool an operator most needs to find. For the full cost picture this article extends, see MCP server in production and agent cost and latency optimization; for the spec revision that introduced the caching hints, see MCP goes stateless.

#mcp #cost #optimization #caching #observability #agents #production