There is a number in the MCP research that should have changed more minds than it did. Researchers working on the RAG-MCP project measured what happens to an agent's ability to pick the right tool as the tool list grows, and as AgentPMT reported in February 2026, selection accuracy fell from 43% to under 14%. Not a slow degradation. A threefold collapse. The same analysis puts standard MCP setups at consuming up to 72% of an agent's context window on tool definitions alone, before the agent has read a single word of your question.
I want to walk through why this happens, what the measured evidence says, and what the numbers look like on a real instance, because most of the discussion I read treats this as a matter of taste. It is not. It is arithmetic.
The arithmetic
Every MCP server you connect hands the model a manifest. Each tool arrives with a name, a description, a parameter schema, and a return type. That text is loaded into the context window and stays there for the whole conversation.
Albato's breakdown of MCP context bloat puts a single tool definition at somewhere between 100 and 500 tokens depending on how verbose the descriptions are, which means five servers averaging thirty tools each gives you 150 definitions and lands you between 30,000 and 60,000 tokens of pure metadata. The team at Arcade measured the same effect from a different angle and found a single forty-tool GitHub server adding ten to fifteen kilobytes of schema to every conversation turn.
Nobody calculates this before connecting. I have not seen a single team do it. We are used to integrations being free until they visibly break, and this one does not break visibly. It degrades.
Three mechanisms, not one
The failure has a shape, and knowing the shape tells you which fix applies.
The first is prompt budget starvation. The context window is finite and everything competes for it: tool schemas, your system prompt, the conversation so far, the data you actually retrieved. When schemas take the majority, the instructions describing how you want the agent to behave get squeezed into what is left.
The second is tool collision, and it is the one that produces the worst answers. Connect several observability servers and you end up with sentry·list_issues, datadog·search_logs, aws·get_log_events, and github·list_issues sitting side by side. To an engineer these are obviously different. As The Daily Agent set out in March 2026, to a model working under heavy context load the semantic boundary between them softens, and it will select one schema while filling in parameters remembered from another.
The third is attention dilution. Transformer attention is not uniform, and accuracy falls when the relevant content is buried in the middle of a long window rather than sitting near either end. Signal from your actual task ends up competing with noise from a couple of hundred definitions that have nothing to do with the request.
These are three different problems. Shortening your descriptions helps the first and does nothing for the second. Only removing overlapping tools helps the second.
What the measured cases say
The most uncomfortable result does not come from a vendor. A paper titled Help or Hurdle? Rethinking Model Context Protocol-Augmented Large Language Models tested MCP-augmented models across three task domains and found that adding MCP tools degraded effectiveness by roughly 9.5% on average across six different models, compared to those same models running standalone. The tools were relevant. The information was real. The models still did worse than with nothing connected at all.
The most useful result comes from GitHub. Writing for the AWS Heroes community in April 2026, the author of MCP tool design, why your AI agent is failing noted that Copilot cut its own tool count from 40 down to 13 and saw measurable benchmark improvements from the reduction. A team with every incentive to expose more capability shipped less of it and got better numbers.
The platforms have responded to the same pressure. The EclipseSource team documented in January 2026 that Anthropic released tool discovery and deferred loading in late 2025, so definitions can be pulled in on demand rather than declared upfront, and Arcade's analysis makes dynamic tool loading the standard runtime recommendation for keeping context lean. Albato's piece puts the practical ceiling, by 2026 consensus, at roughly five to seven connected servers before things degrade.
Read against that backdrop, the posts declaring the protocol a failure that circulated in early 2026 look less like a verdict on MCP and more like teams evaluating it while it was drowning in its own manifests.
What the numbers look like on a real instance
Abstract token counts are easy to nod along to and hard to act on, so here is our own setup at the time of writing.
Our Vörr instance has two connectors attached: Jenkins and Grafana. That is it. Behind them sit seven repositories, two datasources in Loki and Prometheus, and eight Jenkins folders covering the services we run.
Now look at what one of those connectors is actually doing. Grafana alone reports five capabilities: metrics, logs, traces, health, and deploys. One connection, five distinct kinds of question.
That distinction is the whole point, and it is the one most often missed. Coverage and tool count are not the same quantity. The instinct that gets teams into trouble is a reasonable one everywhere else in engineering: more integrations mean fewer gaps, and connecting something you might need later costs nothing today. That reasoning holds for a dashboard. It fails for an agent, because an agent has to choose, and every additional near-identical option makes choosing harder.
Aggregator or orchestrator
I should say plainly that I work at Frigga and Vörr is our product, so weigh the next section accordingly. The design principle matters more than the product.
There are two ways to give an agent access to many systems.
An aggregator connects each system's MCP server directly and lets the agent sort it out. Coverage scales linearly and so does the manifest. This is the path that produces the collapse the RAG-MCP researchers measured.
An orchestrator sits in front of the systems and exposes a small set of verbs. The agent calls get errors, get logs, get metrics, get traces, get service health, get service dependencies. The orchestrator decides which underlying system holds that answer and routes to it. Adding a connector adds coverage without adding a single tool to what the agent sees.
Vörr is built the second way. The tool count is deliberately small and the verbs are deliberately non-overlapping, which is the property that actually matters. Six tools that mean six different things are easier to choose between than forty tools where four of them contain the word logs.
None of this is proprietary insight. Any routing layer gets the same benefit, and you can build a crude one yourself.
What I would check this week
Count tools, not servers. Multiply servers by tools per server. If the product is above roughly a hundred, that is your first suspect, ahead of the model and ahead of your prompts.
Sort the list alphabetically and read it. Every pair of tools from different servers that do roughly the same job is a decision the agent must make with no sound basis. Those pairs produce the confidently wrong answers.
Disconnect before you tune. Most IDEs now allow enabling individual functions rather than whole servers, and switching off twenty tools you never call is faster and more reliable than another round of prompt engineering. It is also reversible in seconds if you were wrong.
Then, and only then, judge the model. Once the manifest is short you can form an honest opinion about whether the agent is any good at the task.
The framing I have landed on is this. Every tool you connect is a question you are asking the agent to answer before it gets to yours. A dozen of those is a fair ask. Two hundred and seventy is not capability, it is a quiz, and the agent will fail the quiz quietly and take your real question down with it.
Author note
I am Mohan Gopi, an Associate DevOps Engineer at Frigga Cloud Labs, where I work on Vörr, connecting code, cloud, and monitoring so that AI answers from the state of a system rather than from a guess. I wrote this because tool count is the one number nobody puts on a dashboard and almost everybody gets wrong. The pattern I keep seeing is teams either connecting every server they can find and blaming the model when it stumbles, or abandoning MCP after two bad weeks and concluding the protocol is broken. It is neither. It is a budget being spent without anyone measuring it. Counted honestly, tool count will tell you why your agent guesses, long before you lose a month rewriting prompts that were never the problem. Left uncounted, it will keep returning answers that are fluent, confident, and about the wrong service.
Let us connect on LinkedIn → Mohan Gopi