Turning off MCP tool search costs you 17,214 tokens before you connect anything
200 MCP tools cost 3,054 tokens deferred and 60,854 loaded. And the switch itself has a price you pay with zero servers configured.
Tool search is documented as keeping “MCP context usage low by deferring tool definitions until Claude needs them.” That is accurate. What the docs do not quantify is how much it saves, or that switching it off costs you something even with no MCP servers configured at all.
I built a minimal stdio MCP server that advertises a controllable number of tools, each with a fixed 798-byte definition (142-character description, three parameters with 130-character descriptions each), and measured reported prompt tokens with tool search on and off.
The numbers
Every figure is a paired baseline: measure with an empty mcpServers block, then with the probe server, back to back. Every measurement below reproduced identically across two runs.
Tool search on (the default):
| Tools | Delta | Per tool |
|---|---|---|
| 5 | +129 | 25.8 |
| 50 | +804 | 16.1 |
| 200 | +3,054 | 15.3 |
Tool search off (ENABLE_TOOL_SEARCH=false):
| Tools | Delta | Per tool |
|---|---|---|
| 5 | +1,574 | 314.8 |
| 50 | +15,254 | 305.1 |
| 200 | +60,854 | 304.3 |
At 200 tools, deferring costs 3,054 tokens against 60,854 loaded. A 95% reduction, or roughly 20x.
The per-tool costs are stable once you are past a handful: about 15 tokens deferred, about 304 tokens loaded, for a 798-byte definition. Scale those to your own schemas accordingly, since a tool with a large parameter schema will cost proportionally more in the loaded case and roughly the same in the deferred one.
The part that surprised me
The two blocks above have different baselines, and I nearly missed why.
With no MCP server configured at all, an empty project reports:
tool search on 57,758
tool search off 74,972Both figures reproduced exactly across two runs. Turning off tool search adds 17,214 tokens to a session with zero MCP servers connected.
The reason is that tool search is not only an MCP mechanism. Claude Code defers a set of its own built-in tools through the same path, and disabling it loads all of them upfront. So ENABLE_TOOL_SEARCH=false is not a neutral switch you flip to make MCP behave predictably. It is a 17k-token charge before you connect your first server.
Combined at 200 tools, the totals are 60,812 with tool search and 135,826 without. That is 75,014 tokens of difference, before the conversation has started.
How this compares to skills
Measuring what skills cost gave 1.4 tokens per skill at scale. Against that:
| Mechanism | Cost each |
|---|---|
| Skill | ~1.4 tokens |
| MCP tool, deferred | ~15 tokens |
| MCP tool, loaded upfront | ~304 tokens |
An MCP tool costs roughly 10 times a skill when deferred, and roughly 200 times a skill when loaded upfront.
That is a real design signal. If a capability can be expressed as a skill, meaning instructions and reference material that Claude reads rather than a callable endpoint into an external system, it is two orders of magnitude cheaper in context than shipping it as an MCP tool. MCP earns its cost when you genuinely need to reach a live external system. It is an expensive way to package what is really a procedure.
Practical upshot
Leave tool search on. It is the default, it saves about 95% at scale, and switching it off has a five-figure token cost of its own that has nothing to do with your servers.
If you have hit a case where you believe you need ENABLE_TOOL_SEARCH=false, measure the session before and after. The switch is far more expensive than it looks, and the cost lands whether or not you connect anything.
All measurements against Claude Code 2.1.223, headless mode, usage from --output-format json, totalling input_tokens + cache_creation_input_tokens + cache_read_input_tokens.
Re-verified 2026-08-07 against Claude Code 2.1.224. Both per-tool figures reproduced identically to the token: +3,054 deferred and +60,854 loaded for 200 tools. The tool-search-off penalty measured +17,795 on 2.1.224, up from the +17,214 recorded here on 2.1.223, because that figure is the gap between two baselines and both baselines moved. Full re-run: every measurement on 2.1.224.
Clarified 2026-08-08. The baseline figures in this post were measured on a machine with a large user-level CLAUDE.md, which loads into every session. That file was separately measured at 26,763 tokens, so Claude Code’s own floor is closer to 31,400 with tool search on. Every delta in this post is unaffected, because each was measured as a paired before-and-after on the same machine and the global config cancels out. Only the absolute baseline numbers are specific to that setup. The calculator now takes user-level config as a separate input.
Corrected again 2026-08-13. The ~31,400 floor quoted just above was itself too high. It was the loaded measurement minus that one file, which left this machine’s user-level skills, MCP servers and plugins sitting inside the supposed floor. Measured directly on 2.1.229, in an empty directory with --setting-sources project so nothing user-level loads at all, Claude Code’s own floor is 22,340 tokens with tool search on and 40,144 with it off, twice per round across four rounds with 0 to 4 tokens of noise. The deltas in this post remain unaffected, and that is now measured rather than asserted: the tool-search gap came back at 17,804 against the 17,795 the old pair implied, 0.06% apart. See the calculator for the full decomposition.
Re-measured 2026-08-14 against Claude Code 2.1.231, and the loaded figure more than doubled. A loaded MCP tool now costs 652 tokens rather than the 304 recorded here, reproducing to the token across four rounds at 5, 50 and 200 tools: 200 tools cost +130,410 rather than +60,854. The deferred side holds, at +3,210 for 200 tools against +3,054, inside this harness’s noise. The tool definition was verified byte-identical at 798 bytes by reading it back out of the probe server’s own tools/list reply, so the fixtures are comparable.
The two arms are not equally solid, and the difference matters. The tool-search-OFF floor did not move at all across four rounds and every loaded cell reproduced to the token in both the curve run and the isolation control, so the loaded arm has a spread of zero. The deferred arm does not: the tool-search-ON floor carries a 521-token component that fires on some calls and not others, which gives every deferred cell a 719-token spread. At 5 tools (median 90) and 50 tools (median 711) that is as large as the measurement itself, so only the 200-tool deferred cell has a signal comfortably above the noise. The published deferred values sit inside that spread at every count, which is the sense in which the deferred curve re-verifies: it is not contradicted, rather than confirmed tightly.
Before accepting the loaded change as real, that arm was re-run with and without --setting-sources project, because the same confound was found the same day to fully explain a different discrepancy on this site. It explains nothing here: the two arms are identical to the token. Nothing identifies what changed or in which release, and the possibility that the earlier figure was itself wrong is not excluded. Every definition is 798 bytes of repeated characters, which is the published fixture and is what makes the comparison valid, but a run of one character tokenises far worse than prose, so a real 798-byte schema will not cost the same: the cross-version comparison is sound, the absolute per-tool figure is specific to this shape. Every run: the re-measured curve.
The conclusion the post is named for gets stronger, not weaker: deferring now saves 41x rather than 20x.
Re-verified 2026-08-15 against Claude Code 2.1.233, and the number in the title of this post is now the highest of four. The saving from leaving tool search on has fallen. Every figure below comes from a corpus that states it, rather than from a floor this post derived itself:
| Claude Code | Tool search off, no servers | Source |
|---|---|---|
| 2.1.223 | +17,214 | this post, above |
| 2.1.224 | +17,795 | this post’s own re-verification |
| 2.1.232 | +17,664 | baseline-floor-2-1-232.json, and the floors in mcp-curve-2-1-232.json agree exactly |
| 2.1.233 | +14,644 | baseline-floor-2-1-233.json |
So the lever is worth 17% less than it was one release ago, and about 15% less than the title says. The practical advice does not change: leaving tool search on is still the single largest context saving this site has measured, and it is still free. What changes is that anyone quoting a specific number for it should say which release they measured on, because this one has moved in three of the four versions checked.
2.1.231 is deliberately absent from that table. The corpus for it publishes the curve deltas but states no tool-search figure, and its tool-search-on floor cell holds two distinct values across rounds. Deriving a single delta from it would be inventing precision the runs do not support, which is exactly the mistake the rest of this post avoids.
Nothing here identifies what changed or in which release. Two independent harnesses agree on 2.1.232 to the token, and the 2.1.233 figure comes from one. No mechanism is claimed, and the possibility that a future release moves it back is not excluded.
Re-verified again 2026-08-17, this time the whole curve rather than the switch cost, and none of it moved. Four rounds on Claude Code 2.1.233, isolation control re-run alongside.
| 5 tools | 50 tools | 200 tools | |
|---|---|---|---|
| Deferred, 2.1.232 → 2.1.233 | +90 → +90 | +810 → +810 | +3,210 → +3,210 |
| Loaded, 2.1.232 → 2.1.233 | +3,270 → +3,270 | +32,610 → +32,610 | +130,410 → +130,410 |
Every cell identical, to the token. Meanwhile both floors moved underneath: tool-search-on from 22,518 to 22,293, and tool-search-off from 40,182 to 36,937.
That is the second per-item curve in a row to hold still through a release that moved its own floor. The skills curve did the same thing two days earlier, unchanged at 39.05 tokens per skill while the tool-search-off floor fell 8%.
Two curves is a pattern, not a law, and I am not going to state it as one. What it supports is a practical habit rather than a mechanism: the floor and the per-item rates have separate release histories, so re-checking one tells you nothing about the other. If you carry a cost model with both in it, they need re-verifying independently. No claim is made here about why, or about whether a third curve would behave the same way.
Every run: mcp-curve-2-1-233.json, and the previous release’s at mcp-curve-2-1-232.json.