Agentic discovery: Fixing tool blindness

Eleven companies, including Microsoft and Google, published the Agentic Resource Discovery specification on June 17 to solve agent blindness. The ARD standard addresses the critical gap where current protocols like MCP handle tool invocation but fail to provide a mechanism for agents to locate those tools in the first place. You will learn how the ai-catalog.json manifest creates a static, trust-anchored record of resources hosted at a predictable domain path. We examine the mechanics of registry crawlers that index these catalogs to function as search engines specifically for agent capabilities. The discussion also covers how this approach supersedes the inefficient practice of flooding context windows with tool descriptions.

The specification builds upon the AI Catalog data model now stewarded by the Linux Foundation. By using domain ownership as a verification method, the protocol allows agents to validate publisher identity before connection. This shift from manual wiring to automated discovery marks the transition of agent ecosystems from brittle, hardcoded configurations to scalable, flexible networks.

The Role of ARD in Standardizing Agentic Ecosystems

Agentic Resource Discovery and the ai-catalog.json Manifest

Agentic Resource Discovery (ARD) defines the runtime protocol for locating agent capabilities, distinct from invocation standards like MCP that execute them. On June 17, eleven companies published this v0.9 specification under an Apache 2.0 license to address the fragmentation where agents cannot dynamically find tools. The specification relies on the ai-catalog.json manifest, a static file hosted at a well-known path that lists available resources with structured metadata. This approach builds directly on the AI Catalog data model currently stewarded by the Linux Foundation.

Unlike manual wiring or context-limited selection, ARD enables registries to crawl and index capabilities across the system. Research indicates the broader environment already includes over 300 distinct resources and frameworks, creating a complex environment for discovery protocols. The manifest accommodates any invocation method, allowing entries for MCP servers, A2A agents, or OpenAPI endpoints. Domain ownership serves as the primary trust anchor, verifying the publisher's identity before an agent establishes a connection.

Reality checks the hype. The specification currently lacks measured adoption outside reference implementations from GitHub and Hugging Face. An independent census of 39 domains, including all eleven contributors, found no discoverable catalogs serving at the set path. This gap highlights a critical dependency: without publishers hosting the JSON file, registries possess no data to index, rendering the discovery layer inert. The value of ARD depends entirely on whether tool providers adopt the catalog format to populate the system.

Solving Fragmentation in the 300+ Tool Agentic System

Agentic Resource Discovery resolves the scalability gap where manual wiring fails against hundreds of thousands of available MCP servers. The system surrounding agentic resource discovery now includes over 300 distinct resources, frameworks, and tools curated as of 2026. This volume exceeds the context window capacity of most models, forcing a shift from static configuration to flexible agent discovery. Unlike invocation, which executes a known function, discovery locates the correct capability before any call occurs.

The Agentic Yellow Pages concept emerges as registries crawl static manifests to index these distributed capabilities. Open discovery invites risk. Without the trust manifest included in ARD entries, agents risk invoking unverified code from unknown publishers. While the specification provides the protocol, actual utility depends entirely on publishers hosting the ai-catalog.json file at their domain roots.

Operators must recognize that discovery does not replace invocation standards like MCP or A2A. The protocol solely addresses the lookup phase, returning the metadata required to establish a connection using existing transport layers. Failure to separate these concerns results in bloated context windows and brittle agent behaviors. Adoption requires publishing the manifest first, as registries cannot index resources that lack a discoverable anchor.

Invocation Protocols MCP and A2A Versus ARD Discovery

MCP standardizes tool invocation mechanics, yet leaves the preceding step of capability location undefined. A2A handles delegation between agents but assumes the target identity is already known. Both protocols manage execution, not discovery. The Agentic Resource Discovery specification fills this gap by defining how agents locate the capabilities before any call occurs.

Manual wiring sufficed when ecosystems were small, but the environment now contains over 300 distinct resources curated in 2026 alone. Loading all tool descriptions into a context window fails at scale, degrading selection quality well before reaching the hard ceiling of a few dozen options. ARD introduces a static manifest, ai-catalog.json, hosted at a well-known path to solve this. Registries crawl these manifests to build searchable indexes, separating the discovery layer from the execution layer.

Separation of concerns drives the architecture. MCP and A2A optimize for stable, low-latency execution, while ARD optimizes for broad visibility across a fragmented market. This division means an agent can dynamically find a new service via ARD yet still execute the task using established MCP servers. However, without widespread publication of ai-catalog.json files, the discovery layer remains empty, rendering the protocol theoretical. Builders must publish these manifests to realize the value of flexible lookup.

Inside the Mechanics of Static Manifest Discovery

The Static Manifest Workflow and Domain Trust Anchors

Publishers place ai-catalog.json at a fixed URL on their domain to expose available capabilities. This static file lists resources like MCP servers, A2A agents, or OpenAPI endpoints alongside structured metadata describing inputs and protocols. Registries crawl these well-known paths using standard web hosting logic, indexing entries without manual intervention. Domain ownership acts as the trust anchor since the entity controlling the URL asserts responsibility for advertised resources. Consuming agents verify publisher identity by checking this domain control before establishing connections, reducing risks tied to unverified tool invocation.

Human-curated directories struggle to track high-velocity changes in agent capabilities. Static lists update periodically. Automated crawling of well-known paths enables discovery at the pace of publication. Tension exists between the simplicity of static files and the need for flexible validation. A catalog file alone does not guarantee the listed resource is currently operational or safe.

Relying on domain control assumes the publisher's infrastructure remains uncompromised. A stolen domain credential could poison the global index with malicious tools. Builders must implement additional runtime checks beyond the initial manifest lookup to maintain resource integrity.

Indexing Nested Catalogs and Structured Metadata

Registries parse structured metadata within entries to map specific inputs, protocols, and functional descriptions for accurate capability matching. Each entry carries structured metadata describing what the resource does, what inputs it accepts, and what protocol it speaks. This parsing logic handles diverse resource types, including MCP servers, A2A agents, or OpenAPI endpoints, ensuring the consuming agent understands execution requirements before invocation. A single catalog entry may also point to a nested catalog, effectively delegating discovery authority to a department's own feed while maintaining the parent domain as the trust anchor. This hierarchical approach allows large organizations to distribute maintenance of their ai-catalog.json files without breaking global indexing.

High velocity in agent development creates a synchronization gap between published manifests and actual capability availability. External indexes tracking the system note that thorough agent lists require regular updates to remain the, reflecting the rapid pace of change in agent capabilities and discovery protocols. Static manifests risk staleness if publishers do not implement automated refresh cycles alongside their deployment pipelines.

Discovery accuracy depends entirely on publisher discipline rather than real-time handshake verification because the files are static. Agents processing these indexes must accommodate large context windows to handle voluminous metadata without truncation. Builders should account for the rapid evolution of the system, where repositories are updated frequently to reflect new agent capabilities.

Semantic Skill-Matching Risks in Complex Taxonomies

Complexity in the agent system necessitates a shift from simple keyword searches to semantic skill-matching and relevance ranking algorithms. Semantic skill-matching replaces brittle keyword queries to navigate taxonomies exceeding 20 functional categories. Moving beyond exact string matches allows registries to interpret natural language task descriptions against structured metadata. This shift addresses the insufficiency of simple search when facing diverse agent capabilities. Platforms like AgentDex demonstrate this by ranking agents based on relevance scores derived from skill alignment rather than static tags.

Reliability gaps appear in this transition that were absent in manual indexing. Community-curated directories often rely on static lists updated regularly, creating latency between capability release and discovery. Utility-based systems execute flexible scoring to rank agents by relevance. Operators deploying relevance ranking algorithms must account for false positives where an agent appears capable but fails execution. Standardized metadata quality is missing, so semantic matching increases noise alongside signal. Builders must validate that structured metadata accurately reflects runtime behavior before trusting automated selection. Relying solely on algorithmic relevance without trust anchors invites injection of malicious or broken tools into the workflow.

Operationalizing Agent Discovery with Registry Crawlers

Defining the ai-catalog.json Static Manifest Structure

Publishers host the ai-catalog.json static manifest at a well-known domain path to list available MCP servers, A2A agents, and OpenAPI endpoints. This file acts as the single source of truth for what an organization exposes to the network. Each entry pairs structured metadata describing inputs and protocols with a trust manifest for identity verification. Converting legacy REST APIs into tools compatible with the Model Context Protocol allows traditional services to participate in structured coordination. A sharp divide separates the spec's broad coalition from current deployment reality. Human-curated directories still power the system because automated crawling cannot function without active publication. Tool providers must publish their own data before registries possess anything to index for autonomous discovery. Builders adopting ARD face an immediate requirement to manually create the initial catalog file before any external agent locates resources. Domain ownership serves as the sole trust anchor, placing full responsibility for advertised resources on the entity controlling the URL.

Deploying Hugging Face Discover Tool and GitHub Agent Finder

Engineers initiate discovery by wrapping existing indexes in the ARD envelope using reference tools. Hugging Face exposes its catalog of Spaces, Skills, and MCP servers through a REST API and command-line interface. This configuration allows operators to publish ai-catalog.json manifests that point to internal resources without migrating data. Simultaneously, GitHub's Agent Finder enables enterprise administrators to curate private registries accessible on all Copilot plans. The mechanism relies on domain ownership as the trust anchor, ensuring agents verify publisher identity before loading tools.

The system surrounding these implementations includes over 300 distinct assets categorized across more than 20 functional areas. Such diversity necessitates strict schema validation because registries reject malformed entries during indexing cycles. Open discovery creates security friction; exposing too many tools increases the attack surface for prompt injection. Loading every available tool description into an LLM's context window hits a hard ceiling at a few dozen options, degrading selection quality well before that limit.

An independent census of 39 domains found no live ai-catalog.json files outside reference implementations. This gap indicates that while the protocol functions, widespread adoption requires manual deployment of static manifests. Without active publishing, registries possess no data to index, rendering discovery layers ineffective. The immediate task for builders is hosting these JSON files to activate the network effect. Until publishers populate the well-known paths, agents remain unable to locate capabilities dynamically.

Validating Domain Ownership Trust Anchors and Nested Catalogs

Since an entry can describe a nested catalog linking to a department's own feed, the specification supports hierarchical discovery where organizations can link to sub-feeds. This structure allows the system to scale from hardcoded configurations to automated discovery layers that reach everything automatically.

The broader system now tracks over 300 distinct inventories across more than 20 functional categories, creating a complex surface area for potential misconfiguration. Orders of magnitude separate what any single agent can see from what actually exists without such structured discovery. Enabling deep, cross-departmental discovery while maintaining a hardened perimeter presents a genuine engineering constraint. Manual wiring worked when agents connected to a handful of well-known tools, but the current scale requires standardized verification to prevent unauthorized actors from injecting malicious tools into the discovery chain.

Strategic Advantages of ARD Over Hardcoded Tooling

Invocation Protocols Versus Discovery Gaps in Agent Standards

MCP standardizes tool invocation but lacks a mechanism for runtime capability location. Existing protocols like A2A and Skills define execution mechanics, assuming the target address is already known. This design creates a discovery gap where agents cannot dynamically locate new resources without manual configuration updates. While invocation standards handle the "how," they ignore the "where," forcing operators to hardcode endpoints or overload context windows with hundreds of static definitions. The system now hosts over 300 distinct allocations across fragmented repositories, making manual wiring unsustainable.

Operators should adopt flexible discovery when managing more than a few dozen tools or when integrating third-party services that update frequently. Relying on hardcoded lists in high-velocity environments degrades selection quality as the gap between available capabilities and known endpoints widens. The ai-catalog.json manifest fills this void by providing a standardized, crawlable index that registries can query before invoking any protocol. However, this approach introduces a dependency on domain stability; if a publisher changes their domain without redirection, the trust anchor breaks and the resource becomes unreachable. Unlike static configurations, flexible discovery requires continuous verification of the trust manifest to prevent hijacking of abandoned domains.

Scaling From Hardcoded Configs to Hundreds of Thousands of MCP Servers

Hardcoded tooling fails once an system exceeds a few dozen options, creating a hard ceiling for agent selection quality. Manual wiring previously sufficed when agents connected to a handful of well-known tools, but the environment now includes hundreds of thousands of available MCP servers. Loading every description into a context window degrades performance long before reaching this scale, leaving orders of magnitude between visible and existing resources. The Awesome AI Agents 2026 repository already curates over 300 distinct holdings across 20 functional categories, illustrating the taxonomy complexity operators face without flexible discovery.

Adopting Agentic Resource Discovery becomes mandatory when tool counts outpace manual configuration cycles. The trade-off is operational overhead; publishers must host an `ai-catalog.json` file at a well-known path to participate. Without this voluntary publication, registries possess no data to index, rendering the discovery layer empty regardless of protocol sophistication. Builders should implement flexible discovery only when their agent platforms require runtime flexibility that static lists cannot provide. Relying on hardcoded lists in a sprawling system forces agents to operate with blinders, ignoring the vast majority of available capabilities simply because they lack a standardized map to find them.

Fragmentation Risks Without Coalition-Backed Discovery Standards

A disjointed environment of over 12 major open-source frameworks threatens to silo agent capabilities before consolidation occurs. Without a unified approach, the system risks fracturing into incompatible proprietary layers where agents cannot locate external tools. This fragmentation forces operators to maintain multiple, conflicting discovery mechanisms rather than a single source of truth. The inclusion of competitors like Microsoft and Google in a shared standard significantly mitigates the probability of such divergent, walled-garden ecosystems emerging. However, converting this specification into functioning infrastructure requires the unglamorous work of persuading thousands of tool providers to host a JSON manifest. Until providers publish these files, registries remain empty, and flexible discovery offers no operational value over static configuration.

The sheer volume of available resources, now exceeding 300 distinct entries in curated lists like Awesome AI Agents 2026, demands a scalable solution. Yet, the primary hurdle remains behavioral: providers must voluntarily expose their capabilities via a well-known path. If substantial players revert to closed loops, the agent system fractures regardless of technical merit. Builders should adopt ARD only if their dependency graph spans multiple vendors requiring neutral lookup. For single-vendor stacks, native discovery tools may suffice without the overhead of manifest maintenance.

References

• How are AI Agents used? Evidence from 177,000 AI