Mcp-context-cost — see what the MCP servers in your Cursor config cost in context tokens, before you type anything

Showcase Built for Cursor
,
1

Every MCP server in your Cursor config injects its tool schemas — names, descriptions, JSON schemas — into the model’s context on every request, whether or not a tool gets called. Cursor has no documented default that defers those definitions, so the total is what every request carries. Nothing in the UI shows you the number.

Setup — no install, no account, nothing written to your project. Run npx -y mcp-context-cost audit

It finds Cursor’s mcp.json (and Claude Desktop, Claude Code, VS Code and Windsurf if you have them), connects to each server, and prints per-server and per-tool token counts, each server’s share of your context window, and which tools you would recover the most by turning off. Env var values are never read into the output, only their names.

I also measured 106 popular MCP servers the same way, so you can see what you are choosing between before you install. The spread is 1,700x: postgres costs 32 tokens, GitHub’s official server costs 54,622 — 27% of a 200K window, spent before the agent does anything. Popularity says nothing about cost: chrome-devtools has 3.3M installs a week and costs 5,717 tokens across 29 tools, while comfyui-mcp has about 4% of that install base and costs 50,640.

Every published number ships with the raw tools/list capture, its SHA-256 and the exact launch command, so any of them re-derives with one command and a dispute reduces to a byte-level diff.

Repo: GitHub - athakur3/mcp-context-cost: Measure what your MCP servers cost you in context tokens — audit your own config, diff a change, gate it in CI · GitHub

Leaderboard, per-server pages and methodology: mcp-context-cost | Measure what your MCP servers cost you in context tokens — audit your own config, diff a change, gate it in CI

MIT, free, built and maintained by me. Happy to be told a number is wrong.

5

I noticed the README distinguishes a catalog measurement from an observation of the client. For Cursor, would “full-catalog estimate” be a better label than “every request carries”? Without a request capture, it’s hard to tell which definitions were actually included.

6

You’re right, and the post is sloppier than the repo it links to. I wrote that Cursor has no documented default that defers tool definitions, “so the total is what every request carries” — and that “so” quietly turns “I couldn’t find documentation” into “here’s how the client behaves”. The README doesn’t do that. Neither does the audit output, which says it in about as many words:

No default deferral is on record for cursor, so every request
carries these tokens before you type anything — an absence of a record
about the client, not a measurement of it.

On the label though, I’d split it rather than call the whole thing an estimate. The count isn’t estimated — it’s whatever the server actually returned from tools/list, captured on the wire, published with its SHA and launch command, re-runnable in one command. The unverified part is narrower than that: what Cursor does with the definitions once it has them. So “full catalog measured, client inclusion unverified” is about what I can stand behind. If Cursor ever documents a default, or somebody captures a request, that half stops being a guess — and the measured half doesn’t move either way.

I went to fix the sentence in the post and it’s past the edit window, so the wrong wording stays up there — this reply is the correction instead. Thanks for catching it.

7

Fair correction on “estimate”—I meant the client-side cost, not your tools/list measurement. “Full catalog measured, client inclusion unverified” says it better. Thanks for adding the correction here.