MCPサーバーにツールを追加したら、Copilot が一方しか呼ばなくなった件The author discovered that adding multiple tools to an MCP server caused VS…

The Model Context Protocol (MCP) has quickly become a common way to connect large language models to external tools and data, and a recent developer report highlights a subtle pitfall: when several tools are registered on a single MCP server, GitHub Copilot in Visual Studio Code may consistently reach for only one of them. For teams building custom MCP servers to extend Copilot's agent capabilities, understanding why this happens matters, because a tool that is never invoked effectively does not exist.

MCP, introduced by Anthropic in late 2024 and since adopted across a range of editors and assistants, defines a standard interface through which a client — such as VS Code's Copilot Chat in agent mode — can discover and call the tools that a server exposes. Each tool typically advertises a name, a natural-language description, and a JSON Schema describing its input parameters. The model does not execute the tools directly; instead, it reads these advertised descriptions and decides, based on the user's request and the surrounding context, which tool to call and with what arguments. That decision is probabilistic and driven by the language model, not by deterministic routing logic.

This design is precisely where the reported problem appears to originate. According to the author, defining two tools on the same server led Copilot to invoke only one of them, even in situations where the other tool seemed to be the better match. The likely cause is that the tool descriptions and schemas were similar enough that the model could not reliably distinguish between them, or that one description was phrased broadly enough to appear to cover both use cases. When descriptions overlap, the model tends to converge on whichever tool seems most generally applicable, leaving the second tool unused.

The practical takeaway is that tool metadata is not boilerplate; it is effectively the prompt that steers the model's selection. The workaround discussed centers on making each tool's purpose unambiguous. That includes writing distinct, specific descriptions that state clearly when the tool should and should not be used, choosing tool names that reflect narrow responsibilities, and tightening the input schemas so the required arguments differ in ways the model can key on. Explicitly noting the intended trigger conditions — for example, describing one tool as handling read operations and the other as handling writes — appears to help the model disambiguate. Reducing the number of tools per server, or splitting responsibilities so each tool has a single clear job, is another commonly recommended practice.

This behavior is not unique to Copilot. Because tool selection is delegated to the underlying model, the same ambiguity can affect other MCP clients and function-calling implementations, including Claude Desktop, Cursor, and applications built directly on the OpenAI or Anthropic function-calling APIs. Vendors have documented that model performance tends to degrade as the number of available tools grows and as their descriptions become less distinct, which is why guidance often suggests keeping tool counts modest and descriptions precise.

For context, VS Code added support for MCP servers to Copilot's agent mode over the course of 2025, allowing developers to plug in local or remote servers that expose custom capabilities alongside built-in features. GitHub Copilot's agent mode can chain multiple tool calls to accomplish a task, which makes reliable tool selection even more consequential: if the agent never considers a tool, entire branches of intended functionality remain inaccessible. Debugging such issues can be awkward, since the failure is silent — there is no error, just an unused tool.

The broader lesson from this report is that building an MCP server is as much an exercise in clear communication with a language model as it is in software engineering. Developers are encouraged to test their servers with realistic prompts, inspect which tools the client actually calls, and iterate on descriptions much as one would refine a prompt. As MCP adoption continues to expand across editors and agents, treating tool descriptions as a first-class part of the design — rather than an afterthought — is likely to become a standard part of the workflow.