There's a moment in every MCP setup where connecting one more server stops helping.
Nothing errors. Nothing disconnects. The agent just gets slightly worse at picking the right tool, and you assume the model is having an off day.
It isn't. You gave it too much to read.
Every connected tool is a tax on every turn
An MCP server's tools don't sit quietly waiting to be called. Their names, descriptions and full input schemas are text, and that text loads before the model can decide whether to use any of them.
Connect five servers with forty tools each and you've spent a serious chunk of the context window before the model has seen a single line of your actual problem.
Two things degrade at once. Context available for real work shrinks. And selection accuracy drops, because the model is choosing from a longer, noisier list.
The second one is the expensive part, and it's invisible. There's no error for picked a plausible but wrong tool.
Claude Code's /mcp panel shows the tool count next to each connected server. Open it. Most people are surprised by the total, and the browser automation server is usually the culprit.
Tool search is already trying to save you
On recent versions this is partly handled. Tool search defers tool schemas by default — instead of loading every definition up front, the model searches for what it needs and expands only those.
A session with dozens of deferred tool names might load the schemas of only the two or three actually touched.
This is also why "connected but the tool isn't available" is often not a bug. The tools are there. They just haven't been expanded yet.
When to override it
Some servers you use every single turn, and waiting for a search step is pure latency. Exempt those:
json
{
"mcpServers": {
"github": {
"type": "http",
"url": "https://api.githubcopilot.com/mcp/",
"alwaysLoad": true
}
}
}
Use it sparingly. Every always-loaded tool consumes context that tool search could have spent surfacing something more relevant. Small, focused servers are reasonable candidates. Large ones are better left deferred — which is exactly the case where you were most tempted to force them on.
One caveat: tool search doesn't run everywhere. It's off with a custom ANTHROPIC_BASE_URL, with ENABLE_TOOL_SEARCH=false, on Amazon Bedrock, on Claude Platform on AWS, on Microsoft Foundry, through a Claude apps gateway, and on Google Cloud's Agent Platform with pre-4.5 models. In those environments you're loading everything up front, and tool count discipline matters far more.
Output is the other half of the bill
Tool definitions are the cost of having a tool available. Tool output is the cost of using it.
Claude Code warns when MCP tool output exceeds 10,000 tokens and caps it at 25,000 by default. That ceiling exists because a single unbounded query against a large table can consume more context than every tool definition you were worried about.
If you're writing your own server, this is the design decision that matters most: return the smallest useful result, not the most complete one. A tool returning 50 rows with a has_more flag beats one returning 5,000 rows and blowing the window.
A rule that holds up
Connect a server when you have a job for it, not because it exists in a directory.
The instinct with MCP is collection — wire up everything, then work out what's useful. That's the wrong shape. Each server should earn its place by doing something you actually asked for in the last week.
If you can't remember the last time the agent called a server's tools, disconnect it. You can add it back in seconds, and the context you get returned is immediate.
The symptoms are all soft
That's what makes this hard to catch. The agent picks a reasonable but incorrect tool. Responses slow down with no obvious cause. Long sessions degrade faster than they used to. Eventually someone says it used to be better at this.
None of those file a bug report. They just quietly erode trust until someone stops using the thing.
It isn't solved by a better model. It's solved by deciding what the agent is allowed to see.
I wrote up the wider version — permissions, transports, logging, timeouts, and the errors that hide real problems — as a 12-point checklist on our site. Every command and figure in both is checked against current documentation.
