Build1 publisher2 min readPublished
A hundred realistic MCP tools cost 11,132 tokens on every model call
A dev.to measurement harness counts cl100k tokens over serialized MCP tool definitions and finds the standing cost grows by roughly 111 tokens for each tool described realistically, and every model call pays it again.
The Engineer · Build desk
What happened
- An MCP client calls tools/list once per session, and whatever tools it ends up holding have their definitions injected into the model's context on every call; a hand-curated manifest pays that too.
- The harness serializes tool definitions as JSON and counts cl100k tokens, anchored on the three real tools of the restaurant sample as the Functions MCP extension serves them, at 277 tokens per call.
- Definition cost grows linearly with tool count at roughly 64 tokens per terse tool, 111 per realistic one and 208 per verbose one, and the verbose multiple over realistic stays near 1.9 at every size.
- The post's thresholds: below roughly ten tools do nothing, thirty realistic tools cost 3,200 tokens per call and about 65,000 per task, and at a hundred tools something has to change.
- Of the four ways the post gives to cut the bill, the curated static manifest is the crudest, and the other three keep live discovery in place.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team comparing MCP against a hand-written tool list is choosing between two things that cost the same per call, so the decision that moves the bill is how many definitions to load and how many turns to permit.
- cost The bill lands on whoever runs the agent, once per model call, so a fleet re-pays the same definition tokens on every run of every task.
- constraint Buying the biggest saving means fixing at design time which five tools matter, and MCP exists so that callers do not have to know that in advance.
- capability A serializer and a tokenizer price this exactly with no model in the loop, so a team can budget definition tokens before it has an eval harness or an API bill.
A hundred realistic tools serialize to 11,132 tokens, and a twenty-call task pays roughly 223,000 of them for definitions before a word of conversation or a byte of tool output [6]. Those definitions crossed the wire once, when the client called tools/list [1], and the model is billed for them twenty times [5]. Each of those twenty requests carries the same manifest that went out on the call before it.
That changes what is worth tuning. Rewriting all hundred descriptions down to sentence fragments moves the slope to roughly 64 tokens per tool, about 6,400 per call [1], saving around 4,700 tokens a call and 94,600 across the task [2]. Getting the same work done in ten calls instead of twenty saves 111,320, with every description left as it is [3].
Static curation is still the largest single cut. Five relevant tools out of the hundred cost 542 tokens per call, 95 percent off, against about 43 percent from stripping every description back [7][6].
For 11,132 to be your number, a few things have to hold. The count is cl100k tokens over a JSON serialization carrying the name, the description, and the input schema with per-parameter descriptions [3]. The tools average two to four parameters and about 25 words of purpose and parameter guidance each [13][16]. Only the three-tool anchor is measured from a running server; the hundred-tool rows are synthetic tools the harness generates, named things like search_invoice and approve_claim [16]. The author notes that harnesses reformat definitions slightly differently, and wrote that you should "treat the absolute numbers as close and the relative differences as solid" [15]. The post does not discuss prompt caching.
The three options that keep discovery intact each attack a different term. Split the server by domain, so an agent connects to the invoice server instead of the everything server. Use a client that defers tool loading and searches definitions on demand, which the post says more agent runtimes now do. Or design coarser, intent-sized tools, so a hundred resource-level operations become fifteen task-level ones [11]. At the realistic slope those fifteen serialize to about 1,670 tokens per call [4]. The post credits a commenter on its predecessor with predicting that last option [19].
Description style is the one place where cheaper is not obviously better. The post's reading is that the verbose tier's extra tokens are mostly prose the model would infer anyway [14]. The 111 tokens per realistic tool buy an agent that picks the right tool and recovers from errors [13]. The earlier post's argument was blunter: vague text makes vague agents [17].
What to watch
- Whether the synthetic tiers get replaced by definitions measured from a real hundred-tool fleet, which would test the 111-token slope.
- Whether agent runtimes that defer tool loading publish savings in the same class as static curation's 95 percent.
- Whether server authors start shipping domain-split endpoints instead of one everything server.