How Many MCP Servers Are Too Many?
Short answer: there is no official limit on how many MCP servers you can connect, and nobody publishes one. There is a practical ceiling though, and you can calculate it yourself. Every server you connect injects its full tool catalog into your agent's context on every request, whether the agent touches those tools or not. At roughly 200 to 500 tokens per tool definition, the math turns against you faster than most people expect.
Why nobody publishes an MCP server limit
The MCP spec sets no maximum. What an [MCP server](/blog/what-is-an-mcp-server) exposes is decided by its author, and what your client does with all those definitions is decided by the client vendor. Each client loads tool schemas its own way, warns you (or doesn't) at its own threshold, and may or may not let you toggle servers per project.
That is why searching for an MCP server limit gets you forum anecdotes instead of documentation. The limit is not a number in a config file. It is a budget, paid in tokens.
The real math on how many MCP servers you can afford
Every tool a server exposes ships a definition: a name, a description, and a JSON schema for its parameters. Well-documented tools with several parameters land at the high end of the 200 to 500 token range. And servers rarely expose just one tool. Five to thirty per server is normal, and big ones go well beyond that.
Take a realistic stack: code host, issue tracker, database, docs tool, messaging. Assume 15 tools per server and an average of 350 tokens per definition.
- 5 servers x 15 tools = 75 tool definitions
- 75 definitions x 350 tokens = 26,250 tokens
That is 26,250 tokens loaded before the model reads a single word of your prompt. Scale it up:
| Servers | Tools (at 15 each) | Schema tokens (at 350 each) | Share of a 200k window |
|---|---|---|---|
| 2 | 30 | 10,500 | about 5% |
| 5 | 75 | 26,250 | about 13% |
| 10 | 150 | 52,500 | about 26% |
| 20 | 300 | 105,000 | over 50% |
At 20 servers, more than half your context window is gone before the task starts. Prompt caching softens the price of repeated tokens, but cached definitions still occupy the window, and changing your tool list invalidates the cache. This standing overhead on every turn is [the context tax](/blog/the-context-tax) in its purest form: you pay for the menu whether or not you order.
Token cost is only half the damage. With 300 tools in context, many of them similarly named (every server brings its own search, list, and get), the model has to pick the right one out of a crowd. Wrong tool calls and hesitation get more common as the catalog grows. Nobody publishes a threshold for that either, but the direction is not in doubt: more tools, worse choices.
The ceiling depends on your client
The same ten servers can be fine in one client and painful in another. Some clients scope servers per project, others load everything globally. Some show you a token count, most don't. So the honest answer to "how many MCP servers is too many" is: fewer than you think in a client that loads everything, more than you think in one that scopes tightly.
Here is a rule of thumb that needs no benchmark: compare your schema overhead to your actual prompt. If the tool definitions cost more tokens than the work you are asking for, you are paying more for the menu than for the meal.
The fix is on-demand loading, not connecting less
The reflex is to disconnect servers. That works, but it is the wrong trade. You give up reach, and the whole point of an agent is that it can act across your tools without you predicting which ones it will need today.
The better fix is to change when definitions get loaded. Put your servers behind an [MCP gateway](/blog/what-is-an-mcp-gateway): one endpoint that federates every server into a single catalog, so tools can be exposed when a task needs them instead of front-loaded on every turn. Ten servers stop costing ten catalogs. There are more tactics, like trimming descriptions and scoping per project, in our guide on [reducing MCP token usage](/blog/reduce-mcp-token-usage).
Full disclosure: this is what we build. [Tulimoa's gateway](/gateway) federates your MCP servers behind one endpoint and adds a memory layer, so the agent recalls IDs and decisions instead of re-fetching them. It is in early beta and not self-serve yet, so the honest pitch is: join the beta, don't expect a sign-up button today.
Frequently asked questions
Is there a hard limit on how many MCP servers I can connect?
No. The protocol sets no maximum and clients rarely document one. The real limit is your context window: every connected server adds its full tool catalog to every request, so the ceiling is wherever schema overhead starts crowding out the actual work.
How many tokens does one MCP server add?
Multiply its tool count by 200 to 500 tokens per definition. A 20-tool server lands somewhere between 4,000 and 10,000 tokens per request, paid whether the agent calls any of those tools or not.
Are too many MCP tools worse than too many servers?
Tools are what count. Three servers exposing 150 tools cost more than ten servers exposing 40 in total. When you audit your setup, count tool definitions, not server entries in your config.
Does disconnecting unused servers solve the problem?
It lowers the overhead, but it caps what your agent can do, and you end up reconnecting things by hand. On-demand loading through a gateway keeps the reach and drops the standing cost.