MCP Context Tax Index

What Context Tax is

When you connect an MCP server to an agent, the agent asks it for a list of its tools. Every tool comes back with a name, a description and a JSON schema for its arguments, and all of that goes into the model’s context window at the start of the conversation and again on every turn. You pay for it whether the model calls a single tool or none. That standing charge is what we call the Context Tax, and it is the number this index measures.

It is not the same as how useful a server is. A heavy server can be worth its weight; a light one can be useless. But the tax is paid up front, it is paid repeatedly, and almost nobody publishes it — so we started every server we could find and wrote it down.

The headline numbers

Sample size matters here, so read it plainly: we attempted 51 servers, 31 started (60.8%), and 30 of those advertised at least one tool and could therefore be priced. That is a small index, not a census of the MCP ecosystem. Installing all 30 priced servers at once would cost 117,168 tokens and 312 tools on every single turn. Median boot time, for the servers that booted, was 8.9s.

Every priced server, heaviest first

Tokens per tool separates two different kinds of expensive. A server can be costly because it exposes a lot of tools, or because each tool carries a large schema. The worst per-tool figure here is Shopify Dev at 1,318 tokens for each of its 5.

The servers that would not start

20 of the 51 servers exited before the protocol handshake finished on a machine with no credentials on it. 10 of those had told us, through their own documentation or startup output, that they wanted an API key or a token first, so their failure is expected and is really a note about setup cost rather than quality. The rest simply died. A server that cannot start unattended is worth knowing about before you put it in an agent loop, so we publish the failures in the same table as the successes rather than dropping them.

How we measured this

Each server is launched over stdio on a clean machine with an empty environment — no API keys, no config file, no prior install. We send the MCP initialize handshake, then tools/list, and record what comes back: the protocol version, the server name and version it reports, the number of tools, the exact byte length of the tools/list response, and the same figure per tool. Boot has 90 seconds; anything slower is recorded as a timeout. We never call a tool, because calling one would do something to somebody else’s account.

Tokens are an estimate, not a count from a tokenizer: we divide the character length of the payload by four, which is the usual rule of thumb for English-and-JSON text. That is accurate enough to compare servers with each other and to size a context budget; it is not accurate enough to reconcile against a bill. Treat every token figure on this page as approximate and comparative. The wider lab procedure is on how we test.

Measured 19 Aug 2026, in one batch. Boot times include fetching the package with npx or uvx on a cold cache, so they are worst-case, and they vary with the network. Servers change: a release that adds three tools moves a row. Cite the date you pulled the data.

Take the data

One row per server, failures included: slug, name, vendor, category, whether it booted, boot milliseconds, tool count, context tax in tokens, tokens per tool, raw tools/list bytes, protocol version and the date we measured it. Free to reuse with attribution (CC BY 4.0) — cite “MrKeyoor MCP Context Tax Index” and link to this page.

Our other index measures whether open-source projects install at all: the Install Success Index. Think a number here is wrong? Name the server and we will re-boot it — contact, corrections policy.