Skip to content

Interoperability

ARD is designed as a superset of existing agent and tool discovery approaches. It is not a replacement for other registries; rather, it acts as a federated overlay that unites them.

  • Universal envelope: Anything can get an ARD entry — an MCP server, a Skill, an ACP agent, an A2A agent, a traditional REST API, or whatever comes next. Entries are identified by IANA media type, so a new kind of artifact needs a new type rather than a revision of this specification.
  • Federated indexing: Once an entry is published, it can be indexed by any ARD discovery service. You don't have to choose between registries; a discovery service can consume all of them, or you can curate your own subset.

How does ARD relate to AI Catalog?

ARD defines its own entry and its own manifest at /.well-known/ard.json. It shares vocabulary with the AI Catalog standard — the same URN form, the same IANA media types, the same trust manifest shape — because the two were developed by overlapping communities.

The relationship is compatibility, not dependency. As of AI Catalog v0.9-RC, an ARD entry carries every member a catalog entry requires — identifier, type, and url or data — so a single document can satisfy both formats' core requirements. Compatibility with later AI Catalog versions is evaluated by the ARD maintainers as those versions are released. ARD additionally expects representative queries, the signal a search service ranks on, which the catalog format does not define. A catalog entry that omits them remains perfectly valid — it simply will not surface in search.

Each specification's conformance is self-contained. A change to what a catalog entry requires does not change what an ARD entry requires, and the reverse; neither is normative for the other. Both may add terms the other does not recognize, and a consumer processes the terms it knows and preserves the rest. An ARD discovery service may also ingest an AI Catalog document directly; when a publisher serves both ard.json and ai-catalog.json with entries that share an identifier, the ard.json entry takes precedence for ARD discovery.

In practice this means a single document can serve both ecosystems today without translating between schemas.

How does ARD relate to registries and tool catalogs?

The ecosystem already has many curated collections of agentic resources: registries for MCP servers and A2A agents, plugin directories like Open Plugins, and platform tool catalogs from some partners. Each is a centralized directory — resources are submitted to it, it owns the canonical list, and clients query that one list. They're useful, but each is an island, with its own onboarding, governance, and reach.

ARD inverts the relationship. Instead of publishing into each collection, a publisher describes a resource once on its own domain (yourdomain.com/.well-known/ard.json), and any discovery service can index it organically — no central gatekeeper, no per-collection re-registration. Discovery becomes a property of the open web, the way search engines crawl sites, rather than a list owned by one operator.

These collections don't disappear in this model — they become ARD discovery services. A registry, plugin directory, or tool catalog can index ARD entries from across the web, apply its own curation and trust policy, and expose the result; clients choose which to query, and they compose. So "ARD vs. a registry" is the wrong axis: ARD is the specification that lets many curated collections — public, vendor, and internal — index the same published resource without anyone having to choose just one.

Is ARD a replacement for MCP or OpenAPI?

No. ARD is a discovery protocol (an envelope), not an execution mechanism. It wraps existing execution standards (like MCP, A2A, and OpenAPI) using standard and proposed IANA media types so clients can find agentic resources dynamically. Once discovered, the client connects to and invokes the agentic resource using its native mechanism (e.g., JSON-RPC for MCP).

How is ARD different from built-in tool search in AI clients?

They're closely related. At one level, a client's built-in tool search is itself an implementation of agentic resource discovery — scoped to the tools that client already has. It chooses among a known, client-managed set, which works well within that boundary.

ARD describes the same idea more generally, and decouples discovery from any single client. The capabilities a task might need can come from many places — internal systems, vendor services, public catalogs, Skills, MCP servers, APIs, workflows, or agents — and ARD lets a client or organization discover which of them should be available in the first place, rather than that universe being fixed by the client implementation.

The two compose naturally. An ARD discovery service can produce a policy-filtered toolbox that a client's built-in tool search then ranks over, or a client can query the discovery service dynamically at task time. Because discovery is decoupled, ranking and filtering can also draw on signals a single client usually can't see on its own: policy, permissions, provenance, trust, usage history, success rates, cost, latency, region, compliance requirements, and deprecation state.

Decoupling discovery from the client is what makes this useful in practice:

  • Enterprise control — an organization can decide which resources are approved, and which are preferred for a given task, and apply policy, permissions, and compliance rules once, centrally, instead of configuring every client by hand.
  • Federation — discovery services compose. A company can run its own service that merges internal resources with selected vendor and public sources and expose it as a single endpoint, while still controlling what is included.
  • Portability — because the discovery layer is separate, the same resources can be found and used across different AI clients and harnesses, rather than being locked to one client's tool universe.
  • Independent evolution — resources can be added, updated, or deprecated without changing the client; a newly published capability becomes discoverable the moment a service indexes it.

In short: built-in tool search selects among known tools; ARD is the layer that decides which tools should be known — and a client's tool search is one natural way to consume it.

What about the ACP Agent Registry

The list of ACP agents in ACP's Agent Registry is already structurally close to an ARD manifest. ACP registries can export their directory manifests as standard ard.json feeds, enabling instant web-scale discovery for editor-context agents — without those agents having to be re-registered anywhere.