MCP Tool Bloat: Why Agents Get Worse After Integrations

MCP tool bloat is what happens when every connected server loads its entire tool catalog into the model's context before the agent does any work. Past roughly 30 to 50 available tools, the agent starts picking the wrong tool and inventing parameters. The symptom looks like a model problem, and it is an inventory problem.

The tell is timing. The agent got worse right after an integration went live, not after anyone touched the prompt. If that sequence sounds familiar, the prompt is not what needs rewriting.

What is MCP tool bloat?

MCP made connecting a system to an agent nearly free. Point it at a server, and the agent gets every tool that server exposes. That is the whole appeal, and it is also the problem: the cost of connecting went to zero while the cost of the resulting inventory did not.

Every tool a server exposes carries a name, a description, an input schema, and argument descriptions. All of it goes into the context window before the first user message. Connect four servers and you are not adding four capabilities. You are adding a few hundred tool definitions the model has to read and choose between on every single turn.

Why does connecting more servers make an agent dumber?

There are two costs here, and teams usually only notice the cheaper one.

The first is tokens. Anthropic's documentation puts a typical multiserver setup, GitHub plus Slack plus Sentry plus Grafana plus Splunk, at roughly 55,000 tokens of definitions before the agent does anything at all. Individual servers back that up. Atlassian's engineering team measured the official GitHub MCP server at 94 tools and roughly 17,600 tokens, and the official Atlassian server at roughly 10,000, and noted that stacking servers pushes past 30,000 tokens of tool descriptions per request.

The second cost is the one that actually hurts, because it never shows up on a bill. Anthropic's own documentation states plainly that tool selection accuracy degrades once you exceed 30 to 50 available tools. That is roughly one and a half MCP servers. You can cross that line with two integrations and a good intention.

This is where the reflex to buy a bigger context window fails. More room to put things does not make the right thing easier to find. The model still has to distinguish between github_create_issue, github_create_pull_request_review_comment, and jira_create_issue on every turn, and adding a hundred more neighbors to that list makes the discrimination harder, not easier. Selection is a needle problem, not a capacity problem.

How do you know tool bloat is your problem?

Three diagnostics, all runnable this week, none requiring anything exotic.

Count the tools actually reachable in a single request. Not the servers, the tools. Most teams are surprised, because nobody adds 94 tools on purpose. They add one server. If that count is north of 50, you have your answer before you measure anything else.

Measure the token cost of definitions alone. Send a request with your full tool array and an empty or trivial user message, then read the input token count. That number is your floor. You pay it on every turn, and it is the number to watch as integrations accumulate.

Log the tool the agent called against the tool the task needed. This is the diagnostic teams skip and the only one that measures the accuracy cost directly. A rising gap between intended and actual tool calls, especially hallucinated tool names and wrong parameter values, is tool bloat showing up as behavior rather than as spend. Watch for retry loops too, because a wrong tool call usually costs several turns, not one.

What are the actual fixes, and what does each one cost?

Three approaches are real. Each has a cost, and the honest version of this advice includes the costs.

On-demand loading. Defer most tool definitions and let the model search the catalog, pulling in only what a request needs. Anthropic documents this as typically cutting definition overhead by more than 85 percent by loading only the 3 to 5 tools required for a given request. Its guidance is to reach for this at 10 or more tools, definitions over 10,000 tokens, or whenever you aggregate multiple MCP servers. The cost is an extra search round trip, and a dependency you might not expect: it only works if your tool names and descriptions are written to be findable. Search cannot rescue a catalog of tools named after internal endpoints.

Compression. Put a proxy in front of the server that rewrites tool descriptions into something denser. Atlassian Labs published an open-source proxy called mcp-compressor in March 2026 with measured numbers: that same 94-tool GitHub catalog dropped from 17,600 tokens to 3,900 at low compression and 500 at max, a 70 to 97 percent reduction, with what the team described as almost no impact on end-to-end quality in their testing. Two caveats worth carrying. That is the vendor benchmarking its own tool, and aggressive compression trims exactly the description text a model uses to choose correctly. Test it against your own task set before trusting the top of that range.

Curation. Do not connect the server because you can. Most agents need a handful of tools, not a catalog, and the fastest path to a reliable agent is usually deleting two integrations nobody uses.

Curation belongs first in that table for a reason. The other two are engineering solutions to a problem that is often a decision nobody made.

How should you design tools so this does not happen again?

If you are building the MCP server rather than consuming one, four things carry most of the weight.

Namespace consistently by service or resource, so a single search matches a whole related group. Prefixes like github_ and slack_ are boring and they work.

Write descriptions the way a person would describe the task, not the way the API documents the endpoint. The model is matching against user intent, and "creates a pull request review comment on a specific line of a diff" is more findable than "POST /repos///pulls//comments".

Keep your three to five most-used tools always loaded and defer the long tail. The common path should never pay for a search.

Then prune on a schedule. A tool catalog is an index, and an index nobody prunes stops being useful. Teams already accept this about database indexes and have not yet extended the instinct to agents.

What this means if you are buying rather than building

If you are evaluating an agent product rather than writing one, this gives you a question worth more than most demos: how many tools does your agent load per request, and do you load them on demand?

The answer separates two kinds of vendors. Every platform demo connects a wall of integrations, because a wall of logos looks like capability. It is the easiest thing to show and the least predictive of whether the thing works on a Tuesday with real data.

Our own instinct runs the other way. On the platforms we have shipped, Smile PreVue, Howdy Dispatch, RunLink, and Copiara in build, reliability came from deciding which tools an agent can even see for a given job, then constraining the surface deliberately rather than exposing everything and hoping the model sorts it out. That is a design decision made per job, not a settings page. It is the least impressive part of our agent orchestration methodology to demo and the part that most determines whether the agent is trustworthy in production.

None of this is exciting. Nobody ships a launch video about pruning a tool catalog. But agent reliability in 2026 is mostly an inventory discipline problem wearing a machine learning costume, and the teams whose agents work are usually the ones who said no to an integration last quarter.

If your agent got worse after you connected something, start by counting the tools. If you want a hand working out which ones your agent should actually see, tell us what you are building. If you would rather learn to do this yourself, that is what /learn is for.