Agentic Resource Discovery (ARD) v0.91 Specification Guide

Quick answer

Agentic Resource Discovery (ARD) is an open specification for describing and searching agents, MCP servers, skills, APIs, workflows, plugins, and other agentic resources across federated registries. The current authoritative specification is v0.91, status Proposal, dated August 26, 2026.

ARD standardizes discovery. It does not define artifact invocation, resource authentication, package distribution, installation, approval, or business authorization. A search result tells a client what may fit a task; a separate trust and execution path decides whether and how it may be used.

ARD v0.91 at a glance

Layer	Current proposal	Important boundary
Entry	JSON-LD node describing one resource	Description is not the running resource
Identity	Domain-anchored urn:air: identifier	A stable handle is not runtime authentication
Artifact	Exactly one of url or inline data	Artifact-specific schemas belong to MCP, A2A, skills, or other formats
Search signals	representativeQueries should contain examples; capabilities may support filters	Searchability and structural validity are different
Static publishing	/.well-known/ard.json, in-page JSON-LD, rel="ard", robots directive, or DNS	Discovery source does not establish trust
Dynamic discovery	Required REST POST /search; optional POST /explore and GET /agents	Ranking and collection policy remain implementation choices
Federation	Search can span or refer to other registries	Federation does not erase local admission or authorization
Trust	Optional trustManifest with publisher binding	Relevance is not trust, compliance, or safety

Source: ARD v0.91 specification, reviewed August 27, 2026.

The ARD entry

The v0.91 proposal defines an entry as a JSON-LD node. A conforming entry must include:

• identifier: a globally unique, domain-anchored discovery handle.
• displayName: a human-readable name.
• type: the artifact media type.
• Exactly one of url or data: a reference to or inline representation of the artifact.

It should include two to five representativeQueries so a registry can build a useful semantic index. The conformance tool warns rather than hard-fails when that signal is missing or under-populated. This preserves structural compatibility, but an entry without good examples may remain practically undiscoverable.

The optional capabilities field supports structured filtering. Optional metadata can include description, tags, version, update time, extensions from other JSON-LD namespaces, and a trust manifest.

ARD entry vs. catalog entry

The current proposal explicitly separates an ARD entry from a generic catalog entry. Every ARD entry is a valid catalog entry, but a catalog listing that lacks ARD discovery signals may not be discoverable through ARD.

That distinction matters during migration. Do not label a manifest ARD-compatible merely because it contains resource names and URLs; validate the current entry terms, identifier, artifact reference, representative queries, and JSON-LD behavior.

Static discovery

Publishers can expose entries through several mechanisms. The current normative well-known path is:

https://{domain}/.well-known/ard.json

Consumers must fetch that path during domain resolution and honor an HTML rel="ard" link. The earlier /.well-known/ai-catalog.json and ai-catalog relation are optional predecessor compatibility paths. A publisher that remains only on the predecessor path may not be found by a conforming consumer.

The proposal also describes in-page JSON-LD, an Agentmap directive in robots.txt, and DNS service-binding records as discovery sources. Test the exact mechanisms your publisher and consumer implement.

Dynamic search API

Every registry must expose the REST search baseline so federation does not depend on one execution protocol:

• POST /search is required and returns resources ranked by relevance.
• POST /explore is optional and returns facets over a collection.
• GET /agents is optional and supports deterministic filtered listing.

MCP or A2A wrappers may be added, but the REST interface remains the interoperability floor. A wrapper is a way to reach discovery; it does not turn ARD into the MCP or A2A execution protocol.

Relevance and trust are separate

Search can return a semantic relevance score from 0 to 100. The specification says that score must not be interpreted as cryptographic trust, compliance, or safety.

An optional trustManifest can carry publisher identity, attestations, provenance, and signatures. ARD requires publisher-domain alignment when the manifest is used but delegates signature and key verification to the declared trust framework. A registry must actually perform that framework’s verification; passing metadata through untouched is not trust validation.

Use the ARD federation, trust, and ranking guide for implementation controls.

Discovery is not invocation

ARD delegates resource authentication to the artifact protocol and leaves physical distribution such as OCI or NPM to implementations. After discovery, a consumer still needs to:

1. Retrieve and validate the authoritative complete entry and artifact.
2. Verify publisher, provenance, signatures, version, and policy.
3. Obtain human or automated admission approval.
4. Install or connect through an approved channel.
5. Authenticate to the resource with minimum scope.
6. Authorize each data and action boundary.
7. Monitor use, cost, changes, failures, and revocation.

Compare these layers in ARD vs. Agent Registry vs. MCP and A2A.

A bounded implementation test

• Pin the v0.91 proposal and recheck for revision changes.
• Publish a small ard.json manifest with stable identifiers and representative queries.
• Run the official conformance tool in manifest and publisher-resolution modes.
• Test required search, pagination, filters, relevance, and incomplete returned entries.
• Test unsupported namespaces and media types without dropping unknown terms.
• Verify publisher identity separately from relevance.
• Keep the collection curated until admission, invocation, and revocation controls pass.

Run the ARD agent catalog readiness check before exposing a production collection.

Frequently asked questions

Is ARD a finished standard?

No. The current authoritative page labels v0.91 as a Proposal. Pin the version and expect changes before treating it as a stable contract.

Is ARD the same as AI Catalog?

The current proposal distinguishes ARD entries from generic catalog entries and replaces predecessor discovery names with ard.json and rel="ard". Compatibility with the old path is optional for consumers.

Does ARD install or run an agent?

No. It describes and searches resources. Installation, authentication, invocation, and action authority belong to other systems and protocols.

Does a high ARD score mean a resource is safe?

No. The score is semantic relevance only. Trust, compliance, safety, approval, and runtime authorization are separate.

Official sources

• ARD v0.91 specification
• How ARD works
• AWS: ARD open specification

Source check: August 27, 2026. Recheck version, status, schemas, well-known paths, endpoints, conformance tooling, trust rules, and media-type registration before implementation.