Agentic Resource Discovery: The ARD Spec Explained

TL;DR
30 sec3 min coredeep dive optional

Agentic Resource Discovery (ARD) is an open specification, at v0.91 as of August 26, 2026, that lets AI clients find agents, MCP servers, skills, and APIs by searching them the way a search engine finds pages, instead of hardcoding each one in advance.

The spec comes from authors at Google, Microsoft, and Hugging Face under Apache 2.0, with AWS among the acknowledged contributors and endorsers, not the owner.
Every capability becomes a JSON-LD entry with a domain-anchored URN identifier, and 2 to 5 natural-language sample queries make it findable by search.
Publishing is gatekeeper-free: host a manifest at /.well-known/ard.json on your own domain and any discovery service may index it.
Trust is deliberately out of scope: relevance scores are not trust ratings, and the anti-squatting rule ties every identifier to a verified publisher domain.

Ask an AI client to book a flight and it will happily call an agent, an MCP server, or an API, as long as someone told it that capability exists. That someone is usually a developer, hand-wiring each client to each resource, and the Agentic Resource Discovery specification argues this is now the bottleneck: invocation got easy, discovery did not. ARD proposes the missing layer, a way for capabilities to be published once and found everywhere, and it arrived the way infrastructure standards increasingly do, written by competing vendors together.

The problem: invocation got easy, discovery did not

Modern agent stacks standardized the calling side. MCP standardizes how a client talks to a tool server, A2A standardizes agent-to-agent transport, and OpenAPI has described REST endpoints for years. What none of them answer is the question a client faces first: which of the thousands of available capabilities is the right one for this task? Today that answer is hardcoded. Each client install or configures the agents and servers it knows about, and connecting a resource to one client does nothing for the others.

The spec also names a scaling wall. Current tool selection stuffs every available tool description into the model’s context window and hopes the model picks well. That works with ten tools and degrades with a thousand. ARD moves selection out of the model entirely: a dedicated search service indexes richer signals, sample queries, publisher identity, structured capabilities, and returns only the few relevant candidates. The unit of the whole system is the “agentic resource,” deliberately broad: an agent, an MCP server, a skill, an API, a workflow, anything external a client can call on.

The entry: one envelope for every capability

An ARD entry is a JSON-LD document that wraps a resource in a handful of required fields. The identifier is a domain-anchored URN of the form urn:air:<publisher>:<namespace>:<agent-name>, and the publisher slot holds a fully qualified domain name, so uniqueness is borrowed from DNS instead of from a central naming committee. The type is an IANA media type string, which is how one envelope covers artifacts as different as an A2A agent card and an MCP server card: each keeps its own native format, and the envelope just says what it is and where it lives, with exactly one of a url reference or inline data.

The signature field is representativeQueries: two to five natural-language questions the resource can actually answer, like “what is the wind speed in Chicago” for a weather server. Discovery services build their semantic indexes from these, and the spec draws a sharp line because of them: an entry without representative queries is still a valid catalog entry, but it cannot be found by search. Valid is not the same as findable, and in this design findable is the point.

Provenance matters for reading the spec correctly. The author list spans Junjie Bu at Google, R.V. Guha at Microsoft, and Shaun Smith at Hugging Face; acknowledgements run from AWS and Cisco to Databricks, GitHub, GoDaddy, Nvidia, Salesforce, and Snowflake. AWS’s August 24, 2026 post is an endorsement from a contributor, and the spec itself moved to v0.91 two days later, repositioning entries onto JSON-LD namespaces. Version 0.91 carries Proposal status, which is standards-speak for “real but not frozen.”

Publishing without a gatekeeper

ARD defines no central registry to approve entries. A publisher serves a manifest at /.well-known/ard.json on its own domain, or uses any of four alternates: JSON-LD markup on a page, an Agentmap directive in robots.txt, an HTML link tag with rel=”ard”, or DNS service records. Consumers carry their own obligations: a conformant client must fetch the well-known path and honor the link tag, with an older predecessor path consulted only as a courtesy. Optional ingestion pipelines add git, npm, and OCI registry scanning for resources that live in repositories rather than on domains.

The design borrows its shape from the web itself. There is no master list of websites; there are pages, and crawlers, and many search engines indexing them with different ranking policies. ARD’s documentation makes the analogy explicit: many discovery services coexist, each with its own trust posture, ranking, and access rules, the way each intranet runs its own search engine. Whoever operates a discovery service becomes an “Agent Finder,” and the live ones already include GitHub’s Agent Finder, Hugging Face’s Discover built into the hf CLI, Cisco’s AI Catalog, and AWS Agent Registry in preview.

The search API and federation

The protocol surface is deliberately small. Every conformant discovery service must expose POST /search, which takes a natural-language text query, optional structured filters, and returns scored results; POST /explore for faceted aggregation and GET /agents for deterministic listing are optional extras. Filters resolve through the same JSON-LD namespaces the entries use, so any term an entry carries can become a filter key without changing the spec, and a publisher-specific term like a service tier filters as cleanly as a core one.

Federation is where the design gets ambitious. A search request carries a federation parameter: auto merges upstream registries into one result set, referrals return pointers to other registries the client may follow, and none keeps the search local. Because every registry speaks the same REST baseline, registry-to-registry routing needs no additional protocol, and the spec’s own worked example walks an orchestrator from an internal expense agent out through a referral to a public registry for a flight-booking agent, then invokes each over its native protocol, A2A for one, MCP for the other.

The context-window economics close the loop: instead of injecting thousands of tool schemas, a client injects the handful its search returned.

Trust is carried, not conferred

The spec is unusually blunt about what it will not do. The 0-to-100 relevance score on every search result ranks semantic fit and nothing else; the spec forbids reading it as any kind of trust signal. What entries can carry is evidence: an optional trustManifest holding an identity binding, attestations, provenance, and signatures, with the protocol requiring only the identity field and staying agnostic about the framework, SPIFFE, DID methods, and enterprise PKI all qualify. The protocol transports the trust signals; the judgment stays with the registry’s curation and the client’s verification.

The pairing with the Agent Name Service states the doctrine in one line: find with ARD, trust the name with ANS. Trust remains the deploying organization’s problem, solved with tools ARD makes portable rather than a stamp the protocol hands out.

Where ARD sits next to MCP and A2A

The layering answer fits in one sentence: ARD sits entirely before invocation. It is an envelope and a discovery protocol, not a runtime, and it does not replace MCP, A2A, skills, or OpenAPI; those keep defining how to call a capability once found. The media-type mechanism is what keeps the layers honest, since an MCP server card and an A2A agent card are just two artifact types the same entry model can point at, and a registry can also surface its own search the same way, as an MCP tool or through an A2A skill, for clients that prefer discovery inside their existing plumbing.

Client reach is already the practical proof. Chatbots including Claude, ChatGPT, GitHub Copilot, and Gemini reach ARD discovery services over a skill or by adding the finder as a remote MCP endpoint, and the project publishes per-chatbot connector guides. For the enterprise case, existing registries do not disappear; they expose ARD manifests and become discovery services, with curation and enforcement staying where it was, which is exactly how AWS positions its own Agent Registry preview: the enforcement point stays put while the interoperability layer goes open.

How does ARD’s anti-squatting rule actually work?

The attack is easy to state: a malicious publisher registers an entry claiming the identifier urn:air:google.com:server:calendar and waits for clients to trust the domain in the name. ARD’s defense is a single normative sentence with real teeth: the cryptographic identity in an entry’s trustManifest must match the publisher domain in the URN. A verifying registry that receives an entry naming google.com without a verifiable attestation from google.com rejects it, full stop.

The mechanism works because of how the identifier is built. Binding identity to a domain name means the root of trust is DNS control, something publishers already defend with established security practices, rather than membership in whatever committee a central registry would need. The spec’s own rationale calls this decoupling identity from location: the URN says who published a capability, the url or data field says where it currently lives, and the two can change independently without breaking the identifier. Move a server from one cloud to another and the entry’s pointer updates while its identity, and its accumulated reputation, stay put.

The honest limits deserve equal attention. The rule verifies publisher identity, not resource quality: an attacker who controls evil.example.com can squat happily on urn:air:evil.example.com entries and rely on search ranking rather than name confusion to do the harm. And enforcement happens at verifying registries, which makes registry competence part of your threat model, one more reason the spec’s insistence that trust decisions stay with the registry and the client is a description of reality rather than a dodge. The anti-squatting rule closes the worst impersonation vector; it does not turn discovery into a guarantee.

Why does the spec refuse to rank trust, and what fills the gap?

A relevance score that quietly became a safety score would be the fastest way to poison the ecosystem. Every discovery service would face pressure to tune its number, vendors would advertise their scores, and users would read a 92 as “verified safe” when the spec defines it as semantic fit for the query. The drafters chose the opposite convention and made it normative: the score is relevance only, and treating it as trust is a spec violation rather than a user error.

What fills the gap is a division of labor the spec describes but does not monopolize. Registries curate: they decide which entries to index, which publishers to require attestations from, and what their own inclusion policies are, which is why an enterprise registry and a public one can carry the same entry with very different vetting. Clients verify: an entry’s trustManifest can carry did:web or SPIFFE identity, signed attestations such as compliance evidence, and provenance records, and the client-side job is checking those before invocation. The live implementations show the pattern maturing already, from scorecards with signed Ed25519 attestations in one directory to transparency-log receipts in another.

The complementary protocols slot into the same division. ANS contributes DNS-style names with PKI-verified identity, summarized by the pairing formula the projects themselves use, find with ARD, trust the name with ANS. Enterprise deployments go further and keep the enforcement point in their existing registry, exposing ARD as the interoperability layer rather than the gatekeeper. The consistent principle across all of it: discovery tells you what exists and how to reach it, and everything that sounds like a guarantee belongs to a different layer with its own accountability.

For practitioners, the operational takeaway is to decide your verification policy before your first federation-enabled search. Auto-federation is powerful precisely because it merges results from registries you may not govern, and the spec is designed so that policy, which registries to trust, which identity frameworks to require, which attestation types count, is configured on your side rather than assumed by the protocol.

Can the governance model actually stay neutral?

The structure is engineered against capture from day one. Direction sits with an Oversight Board of four to seven seats with no company holding more than one, and a seat requires a committed product implementing or supporting ARD: companies earn participation by shipping, not by paying, and the spec states plainly that seats cannot be bought. Day-to-day evolution runs through Maintainers who merge changes by majority vote, with at least two required to be independent members at large. The current board seats Google, Hugging Face, Microsoft, and Amazon, one each, and the maintainer chair is an independent.

The honest answer about neutrality is that it is unresolved by design. The governance documents defer the hard questions openly: term lengths and rotation, quorum and tie-breaking, and the process for companies joining later are all listed as open. The largest deferred decision is structural, whether ARD should move under a neutral host such as the W3C or an AI-focused foundation, placed roughly twelve months out. That timeline is a candid admission that a spec authored by three competing vendors, endorsed by their competitors, has not yet proven it can outlive its founders’ alignment.

There are grounds for optimism in the incentives. Apache 2.0 licensing removes lockup risk, the conformance tooling ships in the repo so no vendor gatekeeps compliance, and the extension mechanism, where any publisher namespace can add filterable terms without a spec change, reduces the fights that usually fracture standards bodies. The acknowledgements list spanning AWS, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, and Snowflake suggests the participation base is already wider than the board.

For adopters, the practical posture is to treat v0.91 as a real but evolving contract. Build against the normative core, the entry format, the well-known manifest, the search endpoint, which is stable enough that multiple registries already interoperate, and watch the governance decisions the way you would watch a dependency’s license change. A standard’s governance model is part of its runtime, and this one says its most important configuration value out loud: to be decided, within twelve months.

Pro tips for evaluating ARD

Publish before you parse: serving a /.well-known/ard.json manifest takes an afternoon and makes your agent indexable by every conformant finder.
Write representativeQueries as real user sentences; they are the semantic index, and generic ones bury you in search.
Treat relevance scores as ranking only and decide your identity-verification policy before enabling auto-federation.
If you run a registry, you are already an ARD discovery service in waiting: expose the manifest and the search endpoint rather than rebuilding both.