Agentic Resource Discovery (ARD)

A Google-announced specification for how agents find capabilities across organizational boundaries — the discovery edge of the agent-interop standards stack, alongside MCP (agent→tool), A2A (agent→agent), WebMCP (agent→web page, added 2026-08-12), Agent Skills (what an agent can do), and AGENTS.md (what it must know). Announced 2026-06-17 by Junjie Bu and Srinivas Krishnan on the Google Developers Blog (T1, the spec’s first-party announcement).

The problem

The other standards assume you already have the endpoint — an MCP server URL, an A2A Agent Card. ARD answers the prior question: given a domain, how does an agent learn what capabilities exist there, confirm they are legitimate, and connect securely? Today that lives in fragmented per-platform registries, so agents can’t discover capabilities across organizations. ARD is the cross-org index layer those registries never agreed on.

Two primitives

• Catalogs. An organization publishes an ai-catalog.json at a well-known path on its domain, listing what it offers — MCP servers, A2A agents, OpenAPI tools, or nested catalogs. Domain ownership is the root of cryptographic identity: a capability’s legitimacy traces to who controls the domain it’s published under. Built on the AI Catalog data model (an AI Catalog Working Group under the Linux Foundation — the same neutral-foundation home as a2a-protocol and agents-md).
• Registries. “Search engines for the agentic web” — they crawl and index catalogs and return matching capabilities with verifiable trust metadata.

The workflow is four phases: publish a catalog → discover (query a registry in plain-language intent, or fetch a known partner’s catalog directly) → cryptographically verify the publisher’s identity → connect at runtime over the capability’s native protocol (MCP, A2A, etc.).

Why it matters here

ARD slots cleanly above the existing interop layer: where MCP/A2A define how a connection works once you have it, ARD defines how you find and trust it in the first place. (One thing the stack framing above did not anticipate: webmcp argues the connection should sometimes not be a server connection at all, which puts a capability inside a page where a catalog entry cannot point at it.) It is deliberately a meta- standard — it doesn’t replace MCP or A2A, it indexes them (an ai-catalog.json entry points at an MCP server or an A2A agent). The governance pattern this spoke keeps noting repeats again: a vendor ships a spec, parks the data model in the Linux Foundation, and bids for it to become the default — the same arc as A2A and AGENTS.md.

Adoption is so far Google’s own: Google Cloud’s Agent Registry in the Gemini Enterprise Agent Platform implements ARD (search/discovery/hosting/governance, globally unique namespaced URNs, Agent Identity verification). One-vendor-deep at announcement.

Cross-spoke facets

• ../ai-governance-wiki — the trust/verification layer (domain-rooted cryptographic identity, “trust manifests” for enterprise compliance) is governance-by-technical-standard, the same shape the IETF AI-crawling work takes there; ARD is the agent-capability counterpart.
• ../search-marketing-wiki — “registries = search engines for the agentic web” is discovery/ visibility for agents: being found in the agentic index is the agent-era analogue of search visibility.

Related

a2a-protocol · model-context-protocol · webmcp · agentskills-spec · agents-md · adk · google · agentic-tooling · synthesis