Too many MCP tools in Cursor? You're paying a context bill that renews every turn.

Cursor loads every connected MCP server's tool list into the model's context. Every schema competes with your actual question for space. A few servers? Noise. Dozens of servers with hundreds of tools can eat a big share of the window before you've typed a thing. It's a tax, and it's charged per turn.

71,929 → 581 tokens

A 50-server, 255-tool catalog. Left: the native tools/list payload with full JSON schemas. Right: mcptoon's names-only index. Measured with tiktoken cl100k_base; source of truth is assets/benchmark_tiktoken.json in the repo. That's −99.2%, and every tool stays callable.

Why Cursor pays this bill

Cursor speaks MCP like every other client. It calls tools/list on each configured server and hands the whole result to the model. The protocol has no "summary mode": name, description, and the full JSON Schema arrive together, whether the agent needs them right now or not. Fine for three servers. Ruinous for thirty.

Here's the part people miss. The cost is per turn, not per use. You pay it again on every message you send, and again on every reply you get. The agent never touched those tools? Doesn't matter. The bill still comes, and it comes out of the same window your real work needs, which is exactly the window that runs out first when a session goes long and the model starts forgetting what you asked it to do in the first place.

This isn't a Cursor bug. Any client that reads full schemas up front pays it. The protocol side is covered in the general tools guide.

How to tell it's your problem

What actually reduces it

ApproachEffectTrade-off
Disconnect servers you "rarely use"smallyou lose the tools, reconnect later
Split servers across projectsmanualyou maintain the split by hand
A gateway serving one name index−99.2%one lookup step, handled for you

The fix: a gateway with a names-only listing

mcptoon sits between Cursor and your servers. Full schemas stay on disk. The agent gets one compact name index instead, and when it wants a tool it fetches that one schema on demand. You keep every server connected. The model stops re-reading every schema, every turn. Everybody wins. Four commands, none of them complicated:

python -m pip install mcptoon
mcptoon demo                 # watch the token math on this machine
mcptoon quickstart           # discover servers, write one config
mcptoon sync                 # push that config into Cursor's mcp.json

Skill catalogs have the same disease. We measured that bill separately too: 489 installed skills, a catalog of 1,572,330 tokens that gets re-read on every single turn, and one resident pointer that cuts the whole thing to 39. That write-up is the skills guide. Want your own number first? The token tax calculator prices your catalog in the browser. Nothing uploads. Nothing leaves your machine.

FAQ

Is there a limit on MCP tools in Cursor?

No hard tool limit is documented. The real ceiling is the context window itself. Every connected tool's schema competes for space each turn, so the cost is per turn, not per use.

Does deleting servers fix it?

Only until you need them again. You lose the capability, you reconnect later, the bill comes back. A name index removes the cost without the loss.

Does this work for other clients?

Yes. One config, pushed everywhere by mcptoon sync: Claude Desktop, Codex, opencode, and more. The AGENTS.md snippet for Cursor lives on the Integrations page.