How many MCP servers is too many?
The context-tax argument you have read everywhere is stale: tool search defers tool definitions by default. Here is what adding servers actually costs now.
Fewer than you think — but almost certainly not for the reason you have read. The popular argument is that every connected MCP server injects its tool definitions into context on every request, so servers are a standing context tax. That is no longer how Claude Code works by default. Tool search is enabled by default and defers tool definitions until Claude needs them, so adding servers has minimal impact on your context window. The costs that remain are real, but they are different ones: discovery accuracy, per-call output limits, prompt-injection surface, and approval friction.
This guide states what the documentation actually says, then gives you the costs worth budgeting against, the cases where the old context tax genuinely still applies, and a short audit.
What changed: tool search is the default
From the Claude Code MCP documentation: "Tool search keeps MCP context usage low by deferring tool definitions until Claude needs them. Only tool names and server instructions load at session start, so adding more MCP servers has minimal impact on your context window." It also states plainly that "Claude Code doesn't impose a fixed per-server tool cap; the practical limit is your context window budget," and that tool search is enabled by default, with MCP tools "deferred rather than loaded into context upfront."
So if you have been rationing servers purely to protect your context window, you have been optimising the wrong variable. Connecting a sixth useful server is not the sin it is usually made out to be.
The costs that are still real
Deferring definitions removes the largest cost, not all of them. Four remain, and they are the ones worth deciding against.
- Discovery accuracy. Tool names and server instructions still load at session start, and Claude searches that surface. Three servers each exposing a plausible
searchtool make the right pick harder to find — overlap, not volume, is what hurts. - Output size. Claude Code warns when a single MCP tool result exceeds 10,000 tokens and caps output at 25,000 tokens by default (
MAX_MCP_OUTPUT_TOKENS). One chatty server returning a giant payload costs you far more context in a single call than ten idle servers cost all session. - Injection surface. Every server is a channel for untrusted content to enter a session that can edit files and run commands. That is a security decision, not a performance one — see hardening Claude Code against prompt injection.
- Startup and approval friction. Each stdio server starts a process, and each new tool is another approval prompt. Servers that fail to connect or need re-authentication add noise to every session.
When the old context tax still applies
Tool search is the default, not a guarantee. In these cases definitions do load upfront and the classic advice becomes correct again — which is exactly why blanket rules are unhelpful:
| Situation | What happens | What to do |
|---|---|---|
A server sets alwaysLoad: true | All of that server's tools load at session start; the docs note each upfront tool consumes context | Reserve it for a couple of tools Claude needs every turn |
ENABLE_TOOL_SEARCH=auto | Schemas load upfront if they fit within 10% of the context window, overflow is deferred | Fine for small sets; watch it as you add servers |
ENABLE_TOOL_SEARCH=false | Everything loads upfront | Then, and only then, ration servers hard |
Bedrock, Google Cloud Agent Platform, Microsoft Foundry, or a custom ANTHROPIC_BASE_URL | Tool search may be off or unsupported | Assume upfront loading and keep the set small |
CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS is set | Tool search stays off and ENABLE_TOOL_SEARCH cannot override it | Unset it, or budget as if definitions load upfront |
Many MCP servers are better as skills
This still holds, and it was always the stronger argument. A large share of what people reach to MCP for is not live external state — it is knowledge or a procedure. "Teach Claude our API conventions" or "how we write migrations" is a skill: a SKILL.md loaded when it is relevant. MCP earns its place when Claude needs to read or act on something live and external.
The test is whether the thing changes minute to minute. A server wrapping a static documentation site is better as a skill or a few files in the repo. A server reading your production database is not, because those rows really do move. For the full breakdown, see skills vs subagents vs commands vs MCP.
| You want | Use | Why |
|---|---|---|
| Live rows from your production database | MCP server | Real-time external state |
| Claude to drive a real browser | MCP server | External actions |
| Read or write issues and pull requests | MCP server | Live external system |
| Your team's API or migration conventions | Skill | Static knowledge, loaded on demand |
| A repeatable review or release procedure | Skill or command | No live system involved |
| Coding-style and repo rules | CLAUDE.md or skill | Always-on context, no tools needed |
A sensible default set
Think in categories rather than vendor names, and keep at most one server per category you genuinely use: a live data source you query, one browser or fetch server if Claude needs to load pages, and one issue or pull-request tracker if you drive tickets from the terminal. A separate filesystem server is usually redundant — Claude Code already reads and writes files in your project.
That is often two or three servers. Not because a fourth would blow your context budget, but because each one you cannot justify is unused surface area: another thing to authenticate, approve, and trust.
How to audit what you have installed
claude mcp list # what is connected right now
claude mcp remove <name> # drop one you are not usingFor each server, ask four questions:
- Have I used a tool from this server in the last month? If not, disconnect it — unused surface is pure downside.
- Does it expose live external state or actions? If it is really static knowledge, replace it with a skill.
- Does it overlap another server's tools? Near-duplicates are what actually degrade tool selection.
- Does it return huge payloads? If you keep hitting the 10,000-token warning, ask for pagination or raise
MAX_MCP_OUTPUT_TOKENSdeliberately.
.mcp.json only loads in that project. A data-warehouse server has no business appearing in your marketing-site repo — scoping it removes the approval noise and the injection surface everywhere else.The mistake to avoid
The mistake is not installing a sixth server. It is repeating a rule of thumb without checking whether the mechanics behind it still hold. Budget against the costs that are real today — overlapping tools, oversized responses, injection surface, approval fatigue — and check your own configuration before assuming the context tax applies to you. If you want guardrails that cost no context at all, that is what hooks are for.