A platform engineering team is building a multi-agent system where new specialized agents may be added to the pipeline over time. Each agent needs to discover which MCP tools are available to it at runtime without requiring a code change every time a new tool is deployed. Which approach best supports this requirement?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Hardcoding tool lists is like printing the restaurant menu into the waiter's uniform — every time the menu changes, you need a new uniform. An MCP registry is the living menu board: agents check it at startup and always get the current list. This is exactly how scalable multi-agent systems handle tool discovery without code coupling.
Full explanation below image
Full Explanation
In dynamic multi-agent systems, the ability to add, remove, or update tools without modifying every agent that might use them is essential for scalability. The MCP protocol supports this through a registry or discovery pattern where agents query available tools at runtime.
Option A is wrong. Hardcoding tool names in system prompts creates tight coupling between agent configuration and the tool infrastructure. Every time a tool is added, removed, or renamed, every agent's system prompt must be updated. This is operationally expensive, error-prone, and scales poorly in systems with many agents and frequently evolving toolsets.
Option B is wrong. While storing tool configs in a repository file is better than hardcoding in prompts (because it can be updated via PR without touching agent code), it still requires a pull request cycle to add or update tools. It also requires agents to parse and interpret an ad hoc file format, and doesn't provide live schema information in MCP's native format. This is a workaround, not the intended architecture.
Option C is correct. An MCP registry is the canonical pattern for dynamic tool discovery in the MCP ecosystem. Agents connect to the registry server at initialization and call the standard MCP list_tools method (or equivalent discovery endpoint) to receive an up-to-date manifest of available tools, their descriptions, input schemas, and endpoint information. New tools can be registered in the registry without touching agent code, enabling the scalable architecture the team needs.
Option D is wrong. Probing every possible tool name via speculative calls is a serious anti-pattern. It generates unnecessary load on tool servers, creates confusing audit logs, may trigger rate limits or side effects from tools that execute actions on invocation, and is completely unmanageable as the number of possible tools grows. This approach also has no mechanism to discover tools whose names are not already known.