Developer measures MCP tool costs: real server tools average about 260 tokens

A developer has put hard numbers on how much context Model Context Protocol tool definitions actually consume, replacing a debate that has mostly run on warnings with something measurable. Writing on dev.to, the author said the post was prompted by widely read articles claiming MCP servers silently drain context windows without anyone publishing an actual count. To fill that gap, they built a synthetic MCP server with the official SDK, listed its tools the way a host application would, and counted the definitions using tiktoken's cl100k tokenizer, then ran the same count against the official filesystem server as a sanity check.

The measurements

The synthetic servers came in at 101 tokens for a single tool, 1,208 tokens for ten tools, and 6,132 tokens for fifty — about 3.07 percent of a 200,000-token context window, or 0.61 percent of a one-million-token window. The real filesystem server, with sixteen tools, weighed 4,204 tokens, or 2.1 percent of a 200k window.

Real tools cost roughly twice the synthetic ones

According to the post, that gap is the most useful finding. The synthetic tools averaged 121 to 123 tokens each, while the filesystem server averaged 263 tokens per tool. The author's guidance is to treat roughly 260 tokens per tool as the realistic figure, because production servers carry longer descriptions and richer schemas than tidy test tools.

The spread inside the filesystem server is wide. edit_file is the heaviest at 408 tokens, followed by directory_tree at 387 and search_files at 376, while copy_file costs 205 and list_allowed_directories, which takes no parameters at all, still costs 154 — the name and description alone carry weight. What makes a tool expensive, the author writes, is a long description, several parameters, and enums or nested objects in its schema. A full example definition in the post shows that much of the weight is not the tool itself but surrounding metadata: a title, schema URLs repeated twice, an output schema, and four annotation flags.

Formatting is not free

One detail the author did not expect: the counts above assume compact JSON with no whitespace. Pretty-printed, the same sixteen tools cost 6,010 tokens instead of 4,204 — a 43 percent jump for whitespace alone. Most hosts send compact JSON, but any host that pretty-prints definitions is paying nearly half again as much for nothing.

The recurring cost

The part the author says nobody mentions is that tool definitions are attached to every request, for as long as the tools are connected, not sent once per conversation. The window only ever holds one copy at a time, so the share of the window stays fixed, but the meter runs on every copy sent. Twenty turns with the filesystem server connected means 84,080 tokens of tool definitions crossing the wire. Three servers of that size would mean 12,612 tokens per request, 6.3 percent of a 200k window, before any conversation happens.

In money terms it stays small: at $1.50 per million input tokens, a price the author cites, 4,204 tokens works out to about six-tenths of a cent per request, or roughly 13 cents over twenty turns. The cost that matters is the window share, not the dollars, because in a long task the context window, not the bill, is the binding constraint.

What actually helps

The author ranks three levers by effect. First, disconnect servers you are not using: a connected server incurs its cost on every request whether or not its tools get called, and this is the only lever that removes the overhead entirely. Second, shorten descriptions, which are the biggest single chunk of most tools and the part authors tend to pad with warnings, examples and restatements; halving a description saves roughly a third of a tool's cost. Third, split large servers and connect only the subset needed, so you pay for half the tools at a time.

What does not help, according to the author, is worrying at small scale. One or two servers on a 200k or 1M window barely register; the overhead becomes worth attention around four or five servers, or on long tasks where the per-request copies pile up.

Caveats

The measurements use one tokenizer, cl100k, and the author cautions that other models count the same text differently, typically within 10 to 20 percent either way, so the figures should be read as a measurement on one ruler rather than a universal constant. The counts also reflect definitions as the client lists them, before any extra fields a host may wrap around them.

Why it matters

The MCP context debate has produced plenty of alarm and few counts. This post supplies a baseline engineers can plan against: budget roughly 260 tokens per tool, remember that every connected server pays that cost on every request, and treat the context window as the resource that runs out first. For tool authors, it also identifies the cheapest fix — terse descriptions and lean schemas directly reduce the per-request cost that every user of the server pays.