MCP can tell an AI agent how to call a tool. It does not tell the agent where every trustworthy tool lives. Agentic Resource Discovery is an early attempt to build that missing map.
Agentic Resource Discovery, or ARD, is an open specification for cataloging, searching, and discovering agents, MCP servers, skills, APIs, and other callable services across multiple registries. The canonical project is at version 0.91 and describes itself as open and evolving.
The idea is timely. Companies are accumulating tool servers and specialist agents faster than operators can find, vet, connect, and retire them. The important caveat is just as large: finding a resource is not the same as trusting it, authorizing it, or proving that it still does what its catalog record claims.
The missing problem is discovery across catalogs
A small team can keep five tools in a configuration file. A large organization can have hundreds of MCP servers, internal APIs, agent cards, skills, and vendor services spread across clouds and business units. Each environment can maintain its own registry, approval workflow, identity system, and metadata format.
ARD proposes a common way for those catalogs to describe and expose resources without moving everything into one global database. Its design is federated and domain-anchored: publishers keep local control while discovery clients can search across compatible services.
ARD, MCP, A2A, and registries solve different layers
| Layer | Primary question | What it does not prove |
|---|---|---|
| ARD | Where can I discover a resource and its catalog metadata? | That the resource is safe, authorized, reachable, or correct |
| MCP | How can a model client interact with tools, resources, or prompts? | That a server should be trusted or globally discoverable |
| A2A or agent card | How does one agent describe and communicate with another? | That an enterprise has approved the agent for this user or task |
| Private registry | Which records has this organization curated in one environment? | That other registries use the same schema or can search it |
| IAM and policy engine | May this identity perform this action now? | That the selected tool is useful or its output is accurate |
AWS uses its Agent Registry to make the distinction concrete. The AWS product can provide a curated catalog, approval workflow, hybrid search, and IAM or JWT access inside an organization. AWS presents ARD as an interoperability layer that could allow catalogs in AWS, other clouds, on-premises systems, and SaaS environments to federate without bespoke pairwise connectors.
The DNS analogy helps, but it can mislead
AWS compares ARD federation to the Domain Name System. The analogy is useful because DNS lets many authorities publish names under domains they control while clients resolve them through a shared protocol.
AI resources require richer decisions than hostname resolution. A catalog may claim that an agent reviews invoices, but a consumer still needs to know who operates it, what data it receives, which tools it can call, how its behavior changed, whether the endpoint was compromised, and whether the current user may invoke it.
Discovery should return a candidate. Policy should decide whether the candidate may act.
A catalog record needs a trust envelope
A useful enterprise record should carry more than a name and description. Before automatic selection, I would require:
- Ownership: verified publisher domain, responsible team, and a reachable security contact.
- Identity: endpoint identity, supported authentication, and key-rotation behavior.
- Scope: input data classes, tool permissions, external effects, and prohibited uses.
- Version: immutable release identifier, change history, compatibility, and retirement date.
- Evidence: conformance results, security review, provenance, and last verification time.
- Operations: region, availability, rate limits, cost, logging, and incident status.
- Revocation: a fast way to remove a compromised or obsolete record from discovery and execution.
These requirements overlap with our review of WebMCP permission boundaries. A standardized description can make a tool easier to call; it should not make dangerous permission choices invisible.
Version 0.91 is a pilot signal, not a universal standard
The ARD repository publishes a specification, schemas, architecture decisions, and conformance tooling under Apache 2.0. That is stronger evidence than a slide deck. It is still version 0.91, with open issues and an explicit invitation for proposals.
AWS contributed feedback and is explaining how ARD could complement Agent Registry. That is meaningful vendor interest, not proof of multi-vendor production consensus. Teams should avoid designing a hard dependency around a draft without an adapter layer and an exit plan.
Run a read-only ARD pilot first
- Select ten low-risk internal resources already approved in an existing registry.
- Publish catalog metadata through one controlled domain without enabling automatic execution.
- Verify ownership, version, endpoint identity, and revocation for every record.
- Ask users and agents to find resources through both keyword and task descriptions.
- Measure discovery success, stale records, wrong matches, missing policy data, and time saved.
- Require a separate IAM and approval decision before any discovered resource is invoked.
- Break the catalog, revoke a record, rotate an endpoint, and confirm consumers fail closed.
This separates the value of discovery from the risk of autonomous selection. It also reveals which metadata your organization needs before it contributes to a shared schema.
The hard problem starts after a match
A discovery service can return three agents that claim to reconcile invoices. The runtime still needs to compare cost, data location, permissions, freshness, failure behavior, and evidence quality. An attacker may also try to manipulate descriptions so a malicious resource ranks for valuable tasks.
Catalog search therefore needs provenance-aware ranking, publisher verification, abuse reporting, and an explicit distinction between “found,” “curated,” and “authorized.” Our guide to agentic AI in plain English makes the same practical point: capability matters less than the permissions and consequences attached to it.
My verdict: standardize the map, keep the gate local
ARD identifies a real scaling problem. A federated discovery layer could reduce duplicate integrations and make internal agent infrastructure easier to reuse across clients and environments.
I would pilot v0.91 as a catalog protocol, not treat it as a trust protocol. Let ARD answer where a candidate resource is described. Keep identity, policy, approval, monitoring, and revocation at the execution boundary until the ecosystem proves much more.
Read the primary sources
- Inspect the canonical ARD v0.91 repository, schemas, and conformance tooling.
- Read AWS’s ARD and Agent Registry architecture explanation.
- Compare the discovery problem with enterprise MCP administration controls.
Checked August 31, 2026. Specification status and scope come from the canonical ARD repository. AWS product and federation claims come from AWS. Comparisons, trust requirements, and the pilot plan are Musthave.ai’s analysis.
