You connected Jira. Then Notion, because the specs live there. Then GitHub, Slack, Linear, and a filesystem server. Every one of them installed cleanly and every one of them works.
And the assistant got worse. Slower to start. Reaching for the wrong tool. Ignoring half of what you asked. Nothing in your setup is broken, which is exactly why it is hard to debug.
Can you connect too many MCP servers?
Yes. Not because any one server is broken - each works exactly as designed - but because every connected server loads its full tool definitions into the model's context before you type anything. Past a certain point the budget left for your actual task shrinks, and the model starts picking between near-identical tool names.
What actually happens when you add the sixth server
Two things degrade at once, and they compound.
The first is budget. Tool definitions are text - names, descriptions, parameter schemas - and the host hands all of them to the model up front so it knows what it can call. Definitions are not free, and they are not conditional: a server you have not used in three weeks still ships its full surface into every conversation. The room left for your files, your question, and the model's own reasoning is whatever remains.
The second is selection. Six servers arrive carrying overlapping vocabularies. Two of them expose something called search. Three can create an item that a human would call a ticket. The model now has to disambiguate between near-identical names on the strength of a one-line description each, and it does that less reliably as the list grows. When it picks wrong, it does not fail loudly - it returns a confident answer from the wrong system.
Neither of these is a defect in MCP or in any of those servers. The degradation is a property of the sum, which is why every individual vendor can be right and your setup can still be worse than it was with two.
You did not have a tool-count problem
Here is where most advice on this goes sideways. Search the problem and you get infrastructure: put a gateway in front of your servers, run a proxy that filters the tool list per request, do dynamic tool discovery, replace tool calls with code execution. Those are real techniques. They are also written by and for people building agent platforms, and at least one of the pages recommending a gateway is published by a company selling one.
If you are a ten-person product team with no platform engineer, none of that is the shortest path to a working assistant. And it skips the more useful question.
Ask why you connected six servers in the first place. Almost nobody does it for six single-system reasons. You did it because the questions you actually wanted answered spanned systems - which accounts asked for this and what do they pay us, which of the things we shipped last quarter moved a metric, is this bug hitting paying customers or free ones. Those are the questions that made you keep adding.
A single-system server cannot answer one of those, and installing more of them does not change that. Five servers that each see one system give you five single-system answers, not one joined one. The join is a data-model problem, not a plumbing problem - we argued that case separately and will not re-run it here. The relevant consequence for your setup today is simpler: adding servers to reach a cross-system answer is a strategy that cannot work, and it is the reason your tool list grew.
So the fix is not a proxy in front of six servers. It is deciding which questions you are actually asking, and connecting the smallest set that can answer them.
Count what you have, then triage it
This takes about ten minutes and needs no new software.
Count it. Ask your AI client, in a fresh conversation: "List every tool you can currently see, grouped by which server provides it, and give me the total count." Read the list. Most people are surprised - not by the number of servers, which they remember, but by the number of tools, which they never chose. That number is the one that matters, and it is yours rather than something a blog post told you.
Sort it. For each server, answer one question: did I ask it something this month? Not could I, not will I when the migration lands - did I. Everything else is loading definitions for a system you do not query.
Disconnect per project, not globally. Most clients scope servers to a workspace or project. The GitHub server belongs on in the repo you are working in and off in the doc-writing project. Keep the two or three that carry a live job in each context; the ones you disable are still installed when you need them back.
Note where a question crossed systems. If the reason a server is on your list is that you wanted an answer joining it to another one, mark it. That is not a triage decision - it is a signal you need one server that reaches across systems rather than several that each stop at their own wall.
| What you connected | The question it can answer alone | Verdict |
|---|---|---|
| Issue tracker (Jira, Linear) | "What's in this sprint, and what's blocked?" | Keep if you ship from it weekly |
| Docs/wiki (Notion, Confluence) | "What does the spec say?" | Keep only in the project where you write specs |
| Code host (GitHub, GitLab) | "What changed in this PR?" | Keep in code projects, disconnect elsewhere |
| Chat (Slack) | "What was said in this channel?" | Disconnect unless you actually query it - the deep search is in the app |
| Filesystem / local server | "What's in these files?" | Keep - genuinely local capability, and correctly local |
| Analytics or billing, added to explain the backlog | Nothing on its own that you asked for | Needs cross-system reach - one server that joins, not two that don't |
Run that against your own list. The rows that end up in the bottom category are the ones that explain why you kept installing.
The part we have to say about our own server
Our hosted MCP exposes 71 tools in a single server. By the arithmetic in this post, that is a lot of definitions to load, and pretending otherwise would make everything above worthless.
Be precise about what does and does not change. The cost is per definition, regardless of whose logo is on the server. One server with 71 tools is not automatically cheaper than three servers with 24 each - that is roughly a wash, and anyone selling consolidation as a token saving is selling you arithmetic that does not hold. What changes is different, and worth naming exactly:
Whether the question is answerable at all. A cross-system question fails against any number of single-system servers. That is a capability difference, not a budget one.
Whether you are loading definitions for systems you never query. A team with a tracker, a feedback tool, an analytics tool, and billing connected has four surfaces resident in context and still cannot join them. That is the case where consolidating is a real reduction - not because one server is inherently leaner, but because you stop paying for four vocabularies to get one answer.
If your questions genuinely stay inside one tool, our server costs you definitions and buys you nothing. Say that back to any vendor, including us.
When several single-system servers are the right answer
There is a real set of teams for whom everything above is the wrong advice.
One system, one job, one team. If your work lives in a tracker and your questions are tracker questions, that vendor's own server is the deepest and most accurate path available, and nothing joined will beat it on its own surface. We ranked those separately, and the ranking still stands.
You already have a joined layer. A warehouse, a CDP, something homegrown. Single-system servers plug into it cleanly, and the join stays where you have already paid for it.
You do have platform engineers. Then the gateway advice is correct rather than aspirational. If you are running agents for many teams across many systems, a proxy that filters the tool list per request is the right control surface and someone on staff can own it. That is a genuinely different problem from the one this post is about, and we work it through separately in MCP gateway: the four routing shapes, and how to pick one. The honest read is that page one is answering that problem - just not for you.
The failure mode is not having six servers. It is having six because you were trying to reach an answer that no single one of them could give you, and treating the resulting slowdown as a tuning problem.
Count your tools, cut to what you asked something this month, and be explicit about which of your remaining questions cross a system boundary. Then decide - what a spine-level MCP exposes and how to connect any client to it is the next thing to read if the answer is that several of them do.
Check the response shape yourself before you decide anything. Run npx -y @aioproductoscom/mcp@latest with no account, no credentials and no signup: started without a PRODUCTOS_TOKEN it runs in demo mode against a fully seeded showcase workspace, with a read-only subset of the tools. A working connection returns typed records with ids, not a paragraph. Ask your host to call whoami on it first - knowing which account an agent is acting as is the fastest way to learn a server's real boundary.