MCPサーバーが増えすぎる前に、ARDで「必要なツールを探す」仕組みを動かすThe article explains Agentic Resource Discovery (ARD), a mechanism that lets AI…

As AI agents increasingly rely on the Model Context Protocol (MCP) to reach external tools and data, the number of MCP servers a single agent can connect to is growing quickly. Agentic Resource Discovery (ARD) is a mechanism designed to address a problem that emerges from that growth: how an agent can find and use the right tools among a sprawling collection of servers without loading everything up front. The idea matters because unchecked server proliferation tends to increase configuration overhead, inflate token usage, and make agents less reliable at choosing the correct tool.

MCP, introduced by Anthropic and now supported across a range of clients including GitHub Copilot, standardizes how AI applications connect to tools, files, and services. Each MCP server exposes a set of capabilities, and a client typically registers those tools so the model can call them. This works well when an agent talks to a handful of servers. As teams add servers for code search, issue tracking, databases, documentation, cloud APIs, and more, the traditional approach of statically declaring every tool starts to break down.

The core issue is that most current setups preload all tool definitions into the model's context. When there are dozens or hundreds of tools, this consumes a large share of the context window before any real work begins, raises cost, and can degrade decision quality because the model must reason over many similar or overlapping options. In practice this often shows up as the agent selecting the wrong tool, or as maintainers manually curating which servers are enabled per project to keep the list manageable.

ARD reframes discovery as a dynamic step rather than a static registration. Instead of exposing every tool at all times, the agent queries a discovery layer at runtime to locate resources relevant to the current task. Conceptually, the agent describes what it needs, the discovery mechanism returns a shortlist of candidate servers or tools, and only those are brought into context for the immediate operation. This keeps the working set small and focused, and it allows new servers to be added to the pool without every agent having to be reconfigured.

On the implementation side, the article describes wiring an agent to a catalog or index of available MCP servers and their capabilities, then having the agent perform a lookup before acting. This lookup can be based on descriptions, metadata, or semantic matching between the task and each server's advertised functions. Because MCP already defines a way for servers to describe their tools, ARD can build on that metadata rather than requiring a new protocol. The pattern appears intended to sit alongside existing MCP infrastructure rather than replace it, acting as a routing or retrieval step in front of tool invocation.

The stated benefits are reduced configuration overhead and improved tool discoverability. By not hardcoding every server into each agent, teams can maintain a shared registry and let agents pull in what they need. Smaller active tool sets are likely to lower token consumption and may improve the accuracy of tool selection, since the model reasons over fewer, more relevant options at any moment. This also makes scaling more graceful: adding a new capability becomes a matter of registering another server rather than editing many client configurations.

It is worth placing ARD in a broader context. The pattern resembles retrieval-augmented generation applied to tools instead of documents, and it echoes techniques such as dynamic tool selection and tool retrieval that several agent frameworks have begun exploring. Related industry efforts include MCP server registries and marketplaces, gateway or proxy layers that aggregate multiple servers, and permissioning systems that gate which tools an agent may call. These adjacent moves suggest the ecosystem is converging on the view that static tool lists do not scale.

Readers should treat ARD as an emerging design pattern rather than a finalized standard. Details such as how discovery is indexed, how relevance is scored, and how security and access control are enforced will likely vary by implementation, and trade-offs around latency and reliability remain to be validated as adoption grows.