What MCP servers actually return

Declared size does not predict delivered size. Not loosely — not at all.

mcp-deepwiki declares 774 B of schema, close to the smallest menu in the census, and returned 62 KB in a single call — 81x its declared size. mcp-sympy declares 63 KB and returned 198 B. Ranked by what they declare, these two servers sit at opposite ends of the table from where they land when ranked by what they deliver.

The install-time number, in other words, tells you almost nothing about the runtime cost — and the install-time number is the only one anyone currently publishes.

Declared against delivered

The distribution

A typical tool response is 580 B. One in twenty is 36 KB or larger. The largest single response measured was 496 KB, from 774 B of declared schema and a handful of bytes of argument.

This is why a fixed context budget behaves unpredictably in practice: the cut point is static, and the pressure on it varies by 6,437x depending on which argument the model happens to pick at runtime.

The same server, measured twice

Two censuses have been run. mcp-deepwiki appears in both, declaring the same 774 B of schema each time, and the size it handed back moved by 11x:

Nothing about the server changed. Its declared size is a constant; only the argument differed. Whatever an install-time number can tell you, it could not have told you this — and no ranking built on declared size survives a 11x swing in what actually gets delivered.

Both runs are published, as census/data/census-r1.jsonl and census/data/census.jsonl. The comparison above is computed from them rather than typed in.

Every measured server

17 further servers declared a menu but exposed no tool that could be called safely without side effects, so they have a declared size and no delivered one. They are in the raw data with their declared sizes intact.

What this is not

Use it

The distribution is published as a versioned document, not a number in a blog post. Fetch it rather than copying constants, and it improves without you editing anything:

https://callwitness.tech/baseline/v1.json

Inside callwitness.baseline.v1, field names, units and meanings will not change. A breaking change becomes v2 at a new path, and v1 keeps resolving. Every server carries its per-call sizes, not only the aggregate, and returned_bytes_all holds every delivered size in one sorted list so any percentile is a line of code away.

Measure your own servers

These are someone else's servers. Yours will differ, and the numbers that matter for your context budget are yours:

pip install callwitness
callwitness run --label docs -- npx -y <your mcp server>
callwitness baseline --out mine.json

That produces the same schema, from your traffic. Anything reading the public baseline reads your file unchanged — the only field to branch on is origin, which is "census" in the published document and "local" in yours.

Make the baseline less thin

The sample above is one person's afternoon. callwitness contribute sends the shape of your traffic — sizes, counts and durations, never arguments, paths, hostnames or results — to widen it. It is off unless you turn it on, nothing is sent while the proxy is running, and --dry-run prints the exact bytes that would leave.