Why Does Claude Code Load None of Its 170 MCP Tools?

The Core Mechanism: On-Demand "Tool Search"

Imagine your development environment is connected to 7 MCP servers, offering a total of 170 tools. Each tool comes with a detailed manual containing functional descriptions and all parameter settings. Loading every one of these manuals into the context window would consume roughly 86,000 tokens. Yet everything else your session loads at startup adds up to only 38,000 tokens. The manuals alone are more than twice the size of everything else combined.

According to analysis from the YouTube channel Agents Unboxed, Claude Code takes a completely different approach: at startup, it loads only the names of the tools. When a task requires a particular tool, Claude searches for it and loads only that single tool's manual. This mechanism is called "tool search."

Understand it with a restaurant metaphor: all you see is the dish names on the menu. The recipes stay in the kitchen until you place an order. According to Anthropic's official data, a typical five-server configuration spends 55,000 tokens on tool manuals, and tool search can cut that overhead by more than 85%.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to give LLMs a standardized way to connect to external tools and data sources. Before MCP, every AI application that wanted to connect to a database, a file system, or a third-party API had to write its own adapter code, resulting in a highly fragmented ecosystem. MCP abstracts this process into a "client-server" model: an MCP server exposes a set of tools with structured descriptions (name, description, parameter schema), and AI clients discover and invoke them through a unified interface. Precisely because a tool's "manual" must be passed to the model alongside the tool, the more MCP servers and the more complex the tools, the more considerable the context overhead becomes—this is the core contradiction that the tool search mechanism is meant to solve.

The context window is the total number of tokens an LLM can "see" in a single inference, including the system prompt, conversation history, tool definitions, retrieved content, and user input. It is not unlimited: mainstream models typically have windows between 128K and 200K tokens, and as the content grows, the model's attention to mid-context information decays noticeably (the "lost in the middle" phenomenon). So when tool manuals occupy 55,000 tokens, it means nearly half the window is consumed by static definitions, severely squeezing the space actually available for code and reasoning. The value of tool search is essentially "on-demand allocation" within this scarce resource pool.

From 55,000 to Under 8,000: Tool Search in Practice

The first clear benefit of tool search is the freeing up of the context window. According to Anthropic's estimates, in a five-server scenario, the 55,000-token overhead of tool manuals is compressed by more than 85%. This means more context space can be left for actual code, conversation history, and task instructions.

The impact on daily use is immediate. The context window is one of the LLM's scarcest resources, and every token saved means the model can "remember" more critical information. When tool manuals no longer monopolize a large chunk of space, Claude's performance in long sessions becomes more stable.

Tool Count Is Not the Only Variable: The Hidden Cost of API Design and Token Efficiency

Beyond context savings, tool search has a second benefit: improving the accuracy of tool selection. Anthropic notes that when more than 30 to 50 tools are available, Claude's ability to pick the right one declines. A leaner tool list keeps the model "sharp."

But there is an often-overlooked issue here: the number of tools does not equal the amount of token consumption. The author of Agents Unboxed shared his own actual configuration data—his N8N server offers 51 tools and consumes 31,000 tokens, while the Instagram server, despite having 22 tools, consumes less than 4,000 tokens. The root of the difference lies in the size of each tool's manual and the complexity of its API design.

This means that even if tool search lets you load on demand, a "heavyweight" MCP server can still consume a large amount of context in a single load. Tool search solves the question of "whether to load," but it cannot solve the question of "how big it is once loaded."

JSON Schema is the mainstream format for describing tool parameters. Each tool's parameter types, enum values, required fields, and nested structures must all be fully expressed in JSON. A tool with simple parameters (such as get_instagram_post(id)) might have a manual of only a few dozen tokens, while a tool with multiple layers of nested objects, a large number of enum options, and detailed field descriptions (such as N8N's complex workflow nodes) might exceed 1,000 tokens for a single manual. This is why "22 tools consuming under 4,000 tokens" and "51 tools consuming 31,000 tokens" can both be true at the same time—token cost is determined jointly by tool count × average manual size, and the latter is often overlooked. For API designers, reducing redundant descriptions, merging similar parameters, and avoiding excessive nesting are all effective ways to lower the token footprint.

Session Stickiness: Once Loaded, It Is Never Released

Tool search is not without its costs. According to Agents Unboxed's observations, once a tool's manual is loaded into the current session, it remains there until the session ends. This means that in a long-running session, as you use more and more tools, the accumulated context consumption gradually climbs.

The design logic behind this mechanism is understandable: frequently unloading and reloading tool manuals could introduce additional latency and complexity. But for developers who need to work for long stretches and involve many kinds of tools, this remains a limitation worth keeping in mind.

In practice, you may need to plan sessions according to task type—splitting unrelated tasks into different sessions to avoid tool manuals accumulating indefinitely within a single session.

KV Cache (key-value cache) is the key to understanding the technical root of "session stickiness." When generating each token, a Transformer needs to reuse the attention key-value pairs of all previous tokens; once these key-value pairs are cached, subsequent inference can skip redundant computation, significantly reducing latency. Tool manuals, as part of the early context, have already entered the KV Cache. To unload them, the cache would have to be rebuilt, at the cost of recomputing the entire prefix—which is both time-consuming and potentially inconsistent. Therefore, engineering practice tends to favor "only add, never remove": once loaded, manuals are written into the cache and retained until the session ends. This explains why the savings from tool search are most apparent in short sessions, but are gradually eroded in long sessions with many tools.

Which of Your MCP Servers Is the "Heaviest"?

Tool search represents an important line of thinking in context management for AI programming tools: rather than cramming all capabilities into the model, let the model "find" what it needs when it needs it. This idea is crucial to the scalability of the MCP ecosystem—if every additional server came at the cost of tens of thousands of tokens, MCP's practicality would be greatly diminished.

But tool search only solves half the problem. API designers still need to pay attention to each tool's manual size and parameter complexity. A well-designed MCP server should be like a concise menu—clear dish names that let the "person ordering" make a choice without long-winded descriptions.

At the end of the video, Agents Unboxed poses a question worth pondering: in your configuration, which MCP server has the heaviest token consumption? The answer to that question may reflect your context management efficiency better than the total number of tools.

One-line Summary

Claude Code uses "tool search" to load MCP tool manuals on demand, cutting token overhead by 85%, but session stickiness remains a hidden cost.

Paragraph Summary

Facing a scenario with 7 MCP servers and 170 tools, Claude Code does not stuff all tool manuals into the context. Instead, it loads only tool names at startup and, when a task triggers a need, searches on demand and loads a single manual—a mechanism called "tool search." Anthropic data shows that the 55,000-token tool overhead of a typical five-server configuration can be cut by more than 85%, freeing up valuable context window space, while a leaner tool list also improves the model's odds of choosing the right tool. But tool search is no panacea: token consumption does not equal tool count—N8N's 51 tools consume 31,000 tokens, while Instagram's 22 tools consume under 4,000, a difference rooted in each tool's manual size and API complexity. Moreover, once a manual is loaded, it stays until the end of the session, so context still accumulates gradually in long sessions. API designers therefore still need to care about the "weight" of each individual tool.