"MCP eats your context" is stale — the new failure is invisible tools

You are about to delete three servers from .mcp.json because a post told you MCP tool schemas eat your context window. Before you do, run /context and look at the MCP tools (deferred) row. On a default modern setup it is a few hundred tokens of tool names, not the tens of thousands of JSON schema you were promised.

Tool search changed the arithmetic. Only tool names and server instructions load at session start; the full schemas stay deferred until Claude searches for a specific tool and pulls it in. Adding servers is close to free. The advice to prune for context reasons was written against the old behavior and mostly no longer applies.

What actually loads now

A server can opt out per-server with "alwaysLoad": true, and an MCP server author can opt out per-tool with "anthropic/alwaysLoad": true in a tool's _meta. Those tools load upfront regardless of ENABLE_TOOL_SEARCH.

The failure that replaced it

Here is the part the docs do not cover. Because tool descriptions are no longer sitting in context, Claude sometimes does not know a capability exists. Practitioners report the symptom as Claude writing a fresh Python script — or a curl, or a shell pipeline — to do something one of your installed MCP servers already does precisely, because the search step never happened. The old failure was loud and measurable: your context window filled up. This one is silent. You get a working answer by the wrong route, and nothing in the transcript flags it unless you were watching for a ToolSearch call that never came.

The docs gesture at the mechanism without naming the failure: server instructions "help Claude understand when to search for your tools," which is only worth saying because the search can miss.

Habits that fit the new shape

• Name the server or tool when you know one exists. "Use the linear MCP server to file this" is not hand-holding any more; it is the discovery hint that replaced having the schema in front of the model.
• If you author a server, spend your effort on the instructions field, not on polishing tool descriptions. Instructions load at session start; descriptions do not. Both are truncated at 2KB, so front-load the important sentence.
• Reach for alwaysLoad on the two or three tools you need on literally every turn, and nothing more. Each one costs context permanently and, on a server, makes startup wait for that server's tool list.
• Scope permissions per tool instead of disabling whole servers. Allow rules take a glob only after a literal mcp__<server>__ prefix, so mcp__github__get_* works and a bare mcp__* allow is skipped with a warning. In headless runs that is a better lever than removing the server.
• Keep the CLI preference. gh, aws, gcloud and friends still cost zero per-tool listing, which is the one context argument against MCP that deferral did not retire. The docs still say so.

What is unverified here

Two separate claims, with different standing:

The mechanism — deferral, the ENABLE_TOOL_SEARCH values, the exception list — is documented plainly and you should treat it as fact.

The failure mode — that Claude reimplements a tool it did not discover — is a community observation from Hacker News follow-up threads to a widely-shared "MCP is broken" post whose author appended a retraction about context usage. Nobody has published a controlled reproduction. It is consistent with how deferral works, and it is exactly the regression you would predict, but "consistent and predictable" is not "measured." The prescriptions above are correspondingly cheap: naming a server in your prompt costs nothing if the concern is imaginary.

What would settle it: configure a server with a distinctively named tool, phrase a task in generic language that never mentions the server, and check whether a ToolSearch call appears before Claude starts writing code. Run it a dozen times, then run the same prompts with ENABLE_TOOL_SEARCH=false and compare. If the deferred runs reach for Bash or Write where the upfront runs reach for the MCP tool, the claim is real and quantified.

Checkpoint

1. Without guessing, is tool search on in your current setup — and which command told you?

   ›Show answerAnswer

   /context is the command, and nothing else reports it — read the MCP tools (deferred) row. A few hundred tokens of tool names means deferral is on and schemas stay out until Claude searches for one; tens of thousands of JSON schema means you are living in the world the old pruning advice described. The figure itself is yours to read off your own session.

   Deferral is off on a non-first-party ANTHROPIC_BASE_URL, with CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS set (which ENABLE_TOOL_SEARCH cannot override), on Microsoft Foundry deployments hosted on Azure, and on pre-4.5-generation models on Google Cloud's Agent Platform.

2. Your teammate says "drop the Sentry MCP server, it is eating our context." What do you check before agreeing, and what would make them right?

   ›Show answerAnswer

   Check the MCP tools (deferred) row in /context before anyone edits .mcp.json. On a default modern setup only tool names and server instructions load at session start, so an extra server is close to free and the arithmetic your teammate is quoting has changed.

   They are right if deferral is genuinely off for you: ENABLE_TOOL_SEARCH=false, one of the exception cases above, or that server marked alwaysLoad. Otherwise deleting it buys back a slice of the few hundred tokens that whole row costs, and risks the newer failure — practitioners report Claude writing a fresh script for a job the removed tool did precisely. That half is a community observation with no published reproduction, so weigh it as a cheap precaution rather than a measured cost.

3. You have one MCP tool Claude needs on every single turn. Which lever do you pull, and what does it cost you?

   ›Show answerAnswer

   alwaysLoad — "alwaysLoad": true to opt a whole server out, or, if you author the server, "anthropic/alwaysLoad": true in that one tool's _meta so only it loads upfront regardless of ENABLE_TOOL_SEARCH.

   It costs you exactly what deferral was saving: that definition sits in context permanently, and at server level startup waits for that server's tool list. Spend it on the two or three tools you need on literally every turn, not on a fleet.