Agentic discovery: Fixing tool blindness

Blog 14 min read

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. The ai-catalog.json manifest answers that gap with a static, trust-anchored record of resources hosted at a predictable domain path, which registry crawlers index to work as a search engine for agent capabilities instead of flooding context windows with tool descriptions. Adoption is the open question: an independent census of 39 domains, including all eleven contributors, found no catalogs served at the well-known path, so the discovery layer stays inert until publishers host the file.

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. 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. Curated lists such as Awesome AI Agents 2026 already track over 300 distinct resources, frameworks, and tools, and they cover only a fraction of that server population. 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.

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.

Feature Static Manifest (ARD) Curated Directory
Update Mechanism Crawler-based Manual review
Trust Model Domain ownership Editor verification
Latency Low (minutes) High (months)
Scale Unlimited Constrained

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 current, 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.

Feature Flat Catalog Nested Catalog
Maintenance Centralized team Distributed owners
Trust Scope Single domain Delegated sub-domain
Update Latency Low Variable

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

Conceptual illustration for Operationalizing Agent Discovery with Registry Crawlers
Conceptual illustration for Operationalizing Agent Discovery with Registry Crawlers

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.

Entries span many functional areas, so registries enforce strict schema validation and reject malformed submissions 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. 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.

Validation Step Target Artifact Risk Mitigated
DNS Ownership Check Root Domain Prevents domain spoofing
Manifest Signature ai-catalog.json Ensures content integrity
Recursive Link Scan Nested Catalogs Blocks injection attacks

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

Bar chart comparing hardcoded tooling limits of roughly 50 against the current 300 distinct resources, alongside metric cards showing 1 million token context windows and monthly update cycles.
Bar chart comparing hardcoded tooling limits of roughly 50 against the current 300 distinct resources, alongside metric cards showing 1 million token context windows and monthly update cycles.

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. With capabilities scattered across fragmented repositories, manual wiring stops scaling.

Feature Hardcoded Tools MCP / A2A ARD Specification
Scope Static binding Execution only Runtime discovery
Scale Limit Dozens of tools Pre-known targets Flexible indexing
Update Model Manual config Fixed endpoint Crawlable manifest
Trust Anchor Implicit Protocol-level Domain ownership

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 ecosystem 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 alone curates over 300 distinct resources, 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. 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.

Dimension Proprietary Discovery ARD Standard
Interoperability Vendor-locked silos Cross-vendor compatible
Adoption Barrier High (custom integration) Low (host one manifest)

The sheer volume of available resources 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.

About

Diego Alvarez, Developer Advocate at AI Agents News, brings hands-on engineering rigor to the analysis of the new ai-catalog.json specification. His daily work involves building and benchmarking autonomous agents using frameworks like CrewAI, AutoGen, and LangGraph, where reliable tool discovery is a critical bottleneck. Unlike theoretical overviews, Diego's evaluation focuses on how this Agentic Resource Discovery standard functions in real-world orchestration scenarios. Having tested countless agent interactions, he understands the friction developers face when integrating disparate tools without a unified schema. At AI Agents News, Diego bridges the gap between emerging industry standards and practical implementation, ensuring engineers understand not just what the Apache 2.0 specification proposes, but how it impacts their immediate build decisions. His background in evaluating failure modes and API reliability allows him to dissect whether this coalition-backed draft truly solves the runtime discovery challenges facing multi-agent systems today.

Conclusion

ARD does not fail or succeed on design. It turns on publication. The specification separates lookup from invocation cleanly, uses domain ownership as the trust anchor, and lets registries crawl whatever publishers expose. None of that produces value while the well-known paths stay empty, and the census of 39 domains, contributors included, is the honest measure of where the standard stands today.

The decision for builders is therefore narrow. If your dependency graph spans several vendors, host an ai-catalog.json for your own services and treat the manifest as infrastructure rather than an experiment, while keeping runtime checks in place, because domain control proves who published an entry and not that the listed resource is live or safe. For a single-vendor stack, native discovery tools still cover the same ground without the maintenance overhead.

Frequently Asked Questions

Registries cannot index resources without the hosted manifest file. An independent census of 39 domains found no discoverable catalogs, meaning the discovery layer remains inert until publishers act.

The ecosystem includes over 300 distinct resources and frameworks today. This volume exceeds context window limits, forcing a necessary shift from static configuration to dynamic agent discovery protocols.

MCP executes known functions but lacks a mechanism to locate them. Discovery finds the correct capability before any call occurs, solving the fragmentation where agents cannot dynamically find tools.

Domain ownership serves as the primary trust anchor for verification. The entity controlling the catalog URL asserts responsibility, allowing agents to validate publisher identity before establishing any connection.

Loading every tool description hits a hard ceiling at a few dozen options. Manual wiring fails against hundreds of thousands of available servers, requiring automated discovery to scale effectively.

References