Claude Code で MCP サーバーを複数接続した際の「未ロードツール」問題 — 遅延ロード方式の実装と3つのハマりどころThis article explains why connecting multiple MCP servers to Claude Code can…

The Model Context Protocol (MCP) has become a common way to extend Claude Code with external capabilities, but developers who wire up several MCP servers at once often discover an awkward side effect: some of the tools they expected to be available never appear to load. This matters because a coding agent that cannot see a tool cannot call it, and silent gaps in tool availability can be difficult to diagnose during real work.

MCP is an open standard, originally published by Anthropic, that defines how language-model clients talk to external servers exposing tools, resources, and prompts. Claude Code, Anthropic's terminal-based agentic coding assistant, acts as an MCP client, and each server it connects to advertises a list of tools along with their names, descriptions, and parameter schemas. Those definitions are normally injected into the model's context so it knows what actions are possible.

The trouble starts when the number of connected servers grows. Every tool definition consumes context tokens before any real work begins, and a handful of feature-rich servers can collectively register dozens or hundreds of tools. The article describes a situation where, past a certain point, not all tool definitions are loaded, leaving portions of the toolset invisible to the model. Beyond the raw token cost, a large, flat list of tools can also make it harder for the model to choose the correct one, which can degrade reliability even when everything technically loads.

The proposed remedy is a lazy-loading approach built around tool search. Rather than exposing every tool upfront, the setup keeps definitions out of the initial context and provides a discovery mechanism that lets the agent query for tools by intent or keyword, then load only the ones it needs for the task at hand. This trades a small amount of latency and an extra step for a much smaller baseline context footprint, and it appears to scale better as more servers are added. The general pattern mirrors work elsewhere in the ecosystem on tool retrieval and on-demand loading, where searching a catalog of tools is treated much like retrieval-augmented generation over documents.

The article then walks through three pitfalls that are easy to hit when implementing this. The specifics are worth reading in full, but the categories will be familiar to anyone who has built retrieval systems. The first tends to involve discoverability: if tool names and descriptions are sparse or ambiguous, search will not surface them, so the metadata that was previously "free" in the context now has to be written carefully enough to be found. The second commonly concerns state and lifecycle, since a tool that is loaded on demand needs to remain available across the turns where it is used, and mishandling that persistence can cause tools to disappear again mid-task. The third often relates to naming and routing across servers, where collisions or inconsistent identifiers make it ambiguous which server should handle a call.

Some background helps put this in perspective. Context windows, though large, are finite and shared with the user's actual code and conversation, so anything that competes for that space carries a real cost. Anthropic and others have been moving toward mechanisms that reduce upfront tool bloat, including tool-search style features and server-side filtering, and the broader agent tooling space appears to be converging on the idea that not every capability should be resident in memory at all times. Configuration in Claude Code is typically handled through project- or user-level files that declare which MCP servers to launch, which makes it straightforward to attach many servers but also easy to overshoot practical limits.

For teams building on Claude Code, the practical takeaway appears to be that connecting more MCP servers is not free, and that a discovery-based loading strategy can restore access to tools that would otherwise be crowded out. As with other retrieval-driven designs, the quality of the outcome is likely to depend heavily on how well the underlying tool metadata is written and maintained. Readers planning a similar setup would do well to treat the three pitfalls as a checklist rather than an afterthought, testing that each expected tool is both discoverable and callable once several servers are running together.