MCP Token Tax Re-Measured: Two Tool Descriptions Drove the Rise

Between 9 and 22 September 2026, the combined tool definitions of nine popular MCP servers grew from 36,320 to 38,738 tokens. That is an increase of 2,418, or 6.7%, and a single server accounts for 2,094 of it. The number of tools barely moved, going from 108 to 109. What grew was the length of the text describing tools that already existed.

The headline numbers

A repeat probe with an identical script, run thirteen days after the first measurement, produced these results:

• The tool block for all nine servers rose by 2,418 tokens, a 6.7% jump.
• firecrawl-mcp went from version 3.24.0 to 3.25.2 and kept exactly 27 tools, yet it contributed 2,094 tokens.
• Inside that server, 2,225 tokens came from heavier definitions of tools that were already present. Two tools were retired and two others added, for a net change of minus 131. The books balance exactly: 892 added, 1,023 removed, 2,225 grown.
• Two tools did nearly all of the growth. firecrawl_scrape and firecrawl_search explain 2,108 of the 2,225, and the description of firecrawl_scrape alone expanded from 1,110 characters to 4,458.
• Cost is concentrated. notion-mcp-server weighs 17,409 tokens (44.9%) and firecrawl-mcp 11,088 (28.6%). Together that is 73.5% of the total, and the other seven servers split the remaining 26.5%.
• Five servers published no release during the window, and they re-probed to byte-identical counts. That unchanged result acts as a control, and it is the reason the difference can be believed.

Why this question matters now

Criticism of MCP has been loud lately, and a central complaint is that servers silently inflate the context an agent carries around. A baseline from 9 September already existed, covering nine servers, 108 tools and 36,320 tokens, so the same probe could be repeated on 22 September. The stack now costs 38,738 tokens, and almost all of the rise comes from one server whose tool count stayed flat because its existing descriptions got longer. That is the critics' claim backed by a number and a published method.

What the token tax is

The token tax is the context budget consumed by tool definitions before the user types anything. Every connected server answers a tools/list call, and that answer is written into the model prompt. For the nine popular servers under watch, the total was 38,738 tokens on 22 September 2026, compared with 36,320 on 9 September. On a 200K window that is about 19% used up ahead of the first message, by a set one developer could easily have installed.

Snapshot taken 22 September 2026 at 18:29 UTC: 9 servers, 109 tools and 38,738 tokens. To reproduce it, probe each npm package spec, then count the strict name, description and inputSchema payload with the o200k_base tokenizer.

How the measurement works

Each server was launched over stdio through npx. The procedure sends initialize, then tools/list, and stores the raw reply. From every tool only the three fields a tool-use API really receives are kept: name, description and inputSchema. The object is canonicalized with sorted keys, tools are sorted by name, and the serialized result is counted with o200k_base. The earlier 9 September run used this same strict definition, and each server was probed at its newest published version on 22 September 2026.

The running server is probed instead of its source code being read, and the distinction is real. Several servers assemble their tool list at runtime, hiding tools behind a flag or composing a description from a template. The array that reaches a model can therefore differ from the one in the repository, and a source read would give a believable number that no model ever sees. Probing has its own limitation: a server that needs credentials may show an unauthenticated client a shorter list than it shows a signed-in user. All nine returned a full list this time, but the method cannot rule that out in general.

Why a thirteen-day difference is believable

Five servers published nothing in the period, so they serve as a built-in control. Those were server-filesystem, server-memory, exa-mcp-server, tavily-mcp and server-sequential-thinking, and they returned to exactly their baseline numbers: 1,668, 907, 415, 1,666 and 867 tokens respectively. Not near them, exactly on them. A drifting probe or tokenizer would have shifted all five, so the whole 2,418 increase lies with the four servers that released.

The server responsible

firecrawl-mcp, with three releases from 12 August to 22 September, is the source of 2,094 added tokens. @playwright/mcp contributed 324 through two releases plus a new tool. Two further servers shipped, @upstash/context7-mcp (two releases) and @notionhq/notion-mcp-server (one), and their tool blocks stayed exactly the same size. Releasing code and changing what goes over the wire are not the same thing, and the latter happens only now and then.

More capable, or just heavier?

Mostly just heavier, which is the fact missing from much of the debate. firecrawl-mcp had 27 tools before and 27 after. It swapped two tools for two others, a change worth minus 131 tokens. The extra 2,225 came from tools already in place getting longer descriptions and larger input schemas for the same capabilities. Users paid 2,225 tokens more for the same twenty-five things they already owned.

The two biggest movers deserve precise figures. firecrawl_scrape gained 721 description tokens and 462 schema tokens. firecrawl_search gained 691 and 234. Combined, that is 2,108 of the 2,225. Seven other surviving tools shifted by only 117 tokens between them, and sixteen did not move at all. The picture is not an ecosystem creeping upward but two tool definitions rewritten at length.

Whether this counts as waste depends on something that was not measured. A longer description is often a legitimate repair: a tool the model kept misusing gets clarified, and the tokens purchase reliability. Still, 4,458 characters is about as long as a full section of prose, attached to one function and transmitted with every request. The cost side was measured properly. The benefit side remains unknown.

Where the tokens actually go

The pattern is concentration and not breadth. Ranked by share of the 38,738 total:

• The Notion server leads by a wide margin at 17,409 tokens, 44.9% of the total, spread over 24 tools.
• Firecrawl is second with 27 tools and 11,088 tokens (28.6%).
• Playwright follows at 3,734 tokens, 9.6%, for 25 tools.
• The reference filesystem server uses 1,668 tokens (4.3%) for 14 tools, and Tavily 1,666 (also 4.3%) for just 5.
• Context7 takes 984 tokens (2.5%) across 2 tools, the memory server 907 (2.3%) across 9, and sequential-thinking 867 (2.2%) for a single tool.
• Exa is the lightest, 415 tokens or 1.1%, with 2 tools.

Tool count predicts cost poorly. @playwright/mcp offers 25 tools for 3,734 tokens, while notion-mcp-server offers 24 for 17,409. The tool counts are nearly equal and the bill is 4.7 times larger.

For anyone running more than two or three servers, the useful question is which of them are the Notion-shaped ones.

Is the criticism correct?

On this claim, in this sample and window, yes, though the mechanism is narrower than the debate usually implies. Cost is rising, it is rising without new capability, and it sits in a handful of servers instead of being spread through the ecosystem. The common charge that MCP as a protocol is inherently bloated is not what the data show. What the data show is that the prose of two vendors makes up most of the bill.

Limits of the evidence

• No trend is shown. Two points thirteen days apart form a difference, not a trajectory, and one of the two is dominated by a single vendor's release. A quiet month would give a flat or negative number without the problem going away.
• The sample does not represent MCP as a whole. These nine servers were picked in an earlier round because they are widely installed and can be probed without credentials. Thousands of servers exist and nobody has a reliable list of them.
• Real agents are not modeled. Nobody connects exactly these nine, so 38,738 describes a stack that was defined for the exercise and not a bill anyone pays. The reusable part is the method, which can be run on any personal set of servers.
• Value is unmeasured. firecrawl_scrape's description quadrupled in length, but whether the model now calls it correctly more often needs an eval harness, which is a different experiment.

A check on the first draft of the number

The first attempt used naive serialization, the full tool object as returned. It gave 40,480 tokens for the 9 September corpus, against 36,320 already published. The gap was not a change in the servers. It was extra wire fields that the published method deliberately leaves out.

Repeating the run with the archived strict definition gave back 108 tools and 36,320 tokens to the unit, hence the control above. Two different methods compared give an artifact, not a measurement, and here the artifact would have inflated the change by 6.5% in the more eye-catching direction.

The same caution applies to earlier work on the topic. A prior piece reported 38,900 tokens for nine MCP servers, but that number came from a different run whose method was not re-verified, so it is not the baseline here. The value 38,738 is not a decline from 38,900. The only pair that can be honestly subtracted is 36,320 and 38,738, since one script produced both.

Common questions

What counts as the token tax? Everything a client hands the model about tools before any conversation begins: in practice each server's tools/list reply trimmed to name, description and input schema. Every request in a session carries it unless the client caches the prefix, and it is charged even if no tool gets called.

Does prompt caching make it free? Cheaper, not free, and only as long as the prefix does not change. Looking at 96 releases across these nine servers, 48% of version transitions altered the tool block that opens a cached prefix. Frequent releases mean frequent cache invalidation.

Why is notion-mcp-server so costly? Its 24 tools carry input schemas that describe a big API surface, and the tool block has stayed untouched since July. No growth is involved. It began high and stayed there, which is a separate issue from cheap-but-churning servers and calls for a different response.

Can unused tools be switched off? A few clients let a server's tools be filtered, and with these figures that is the most effective option on the table, because removing the two priciest servers would trim the stack by 73.5%. Client support varies, so it is smart to check that before installing yet another server.

Does 6.7% in under two weeks count as large? Extrapolated to a year it would sound alarming, but projecting from two data points is misleading. What happened is one two-week stretch where a single vendor release put 2,094 more tokens into a nine-server stack with no new capability.

A check worth doing today

Open the agent's MCP config, count the servers, and find the largest one. Did its tool descriptions grow the last time it updated, and would the change have been noticed? One open question remains too: how many tokens a client really sends when it claims to filter a server's tools, a number that is assumed here and never verified.