Compatibility with the June path is optional

The June Hugging Face announcement points publishers to /.well-known/ai-catalog.json. Version 0.91 calls that the predecessor path. A conforming consumer must fetch /.well-known/ard.json and honor a rel="ard" link. Reading the old path and the ai-catalog relation is optional.

That detail can make a resource vanish from search. A publisher serving only the old file may be invisible to a new client. A client supporting only the new file can miss catalogs made with early implementations. The Hugging Face hf-discover repository still documents client-side navigation that begins at /.well-known/ai-catalog.json, so a transition layer has practical value.

Keep both paths inside one resolver instead of repeating them throughout an application. While the draft settles, the resolver can try the new path first, accept the predecessor with a warning, record which format supplied each entry, and test fixtures for both. ARD's conformance tooling takes a similar approach. It resolves ard.json, falls back to the predecessor, and warns that other consumers need not do so.

What an ARD entry describes

Version 0.91 defines an ARD entry as a JSON-LD node describing one searchable resource. It has an identifier, display name, media type, and either a URL or inline data. Optional terms cover capabilities, representative queries, metadata, and a trust manifest.

A small publisher document could be:

{
  "entries": [
    {
      "identifier": "urn:air:example.com:server:weather",
      "displayName": "Weather Data Node",
      "type": "application/mcp-server-card+json",
      "url": "https://api.example.com/mcp/weather.json",
      "capabilities": ["WeatherTool"],
      "representativeQueries": [
        "get the current wind speed",
        "find a five-day forecast"
      ]
    }
  ]
}

Registries crawl these entries and expose a REST search interface. Text queries provide semantic relevance. Structured filters can narrow results by media type, publisher, capability, or fields in a trust manifest. A client can tell a registry to search upstream registries, return referrals, or search only its local index.

ARD's envelope covers more than MCP. It can describe MCP server cards, A2A agent cards, skills, APIs, datasets, and other registries. Protocol-specific catalogs still have a role. The official MCP Registry, for instance, stores standardized metadata for public MCP servers and leaves curation and extra security checks to downstream aggregators. ARD makes several resource types and registries searchable through one discovery model.

Relevance is not a security verdict

The ARD search score measures semantic relevance. The specification says it must not be treated as a judgment about trust, compliance, or safety.

Suppose an agent searches for a service that can upload a report. A result may match perfectly while coming from an unapproved publisher, lacking a security review, or handling confidential files in a forbidden region. The user may not have authorized an upload. Ranking cannot settle any of those questions.

ARD provides a place to carry trust information. The optional trustManifest may include identity, attestations, provenance, and signatures. When a manifest is present, the publisher domain in the entry identifier must match its trust identity. ARD does not prescribe one signing and verification system. It assigns that work to the framework named by the trust manifest, and an entry can be structurally valid without one.

AWS's August 24 explanation of ARD and Agent Registry draws the boundary clearly. ARD provides interoperability across registries. Approval and authorization stay with the local registry and its enforcement point. The same division applies outside AWS.

From search result to permitted tool

An agent host should treat a discovery result as a candidate. Before calling the tool, the host needs to:

1. Search only registries allowed by local policy and retain the source registry for each result.
2. Resolve the authoritative entry, then validate its schema and identifier.
3. Verify the publisher identity and declared attestations through the stated trust framework.
4. Apply policy for the current user, data classification, environment, and requested action.
5. Fetch or install the resource only after those checks pass.
6. Give it the runtime permissions needed for this task, then record selection and invocation as separate events.

The same separation makes sense in a consumer product. ish.chat can find a capability without connecting it silently. An orchestrator built through api.ish.chat can hold search results as untrusted metadata until policy admits one. Our guide to A2A and MCP makes a related distinction: an interface explains how components communicate, not what either side is allowed to do.

Build for another draft

Moving hundreds of tool descriptions out of a prompt and into search has a clear benefit. Registries can index fuller descriptions, apply filters, and combine private and public catalogs without teaching every client about each source in advance.

ARD v0.91 is still a proposal. It changed the canonical publication path and recast entries as JSON-LD nodes while keeping existing manifest entries valid. More changes are plausible.

Pin the version your client implements, hide discovery behind an adapter, and test both publication paths during the transition. Keep the final boundary explicit in code: ARD returns candidates, while local policy decides which resource can be installed, connected, and invoked.