An agent with one MCP server wired into it has no discovery problem. An agent that is supposed to operate across the open web — book a flight it has never booked, query a database at a company it has never touched, hand a subtask to some other team's agent — has a very large one. It has to answer three questions before it can do anything useful: where does the right capability live, which of several should I use, and can I trust it enough to connect? For a year the industry answered those questions in a dozen incompatible ways, one per cloud, each vendor's registry blind to the others.

On June 17, 2026, eleven of those vendors stopped fighting long enough to publish a shared answer. Agentic Resource Discovery — ARD — is a draft specification, Apache 2.0, co-signed by Google, Microsoft, Cisco, Databricks, GitHub, Nvidia, Salesforce, ServiceNow, Snowflake, Hugging Face, and GoDaddy. That is an unusually broad room to agree on anything. The reason they could is that ARD is careful, almost stubborn, about what it declines to be.

Two primitives, and nothing else#

The whole spec is two moving parts. First, a publisher hosts a static manifest at /.well-known/ai-catalog.json on its own domain — a list of the tools, MCP servers, A2A agents, and APIs it exposes. Second, registries crawl those manifests, index them, and expose a search API. An agent sends a natural-language task description to a registry and gets back ranked matches, each with a relevance score and the metadata needed to verify the publisher.

Note who talks to whom. The agent does not read your catalog file directly; it asks a registry. The draft mandates a POST /search endpoint whose body carries a query.text — the plain-language need — an optional query.filter of structured constraints, and a federation mode, and returns entries scored 0–100 by semantic relevance with a pointer to the source registry. This is the part people miss when they call ARD "robots.txt for agents." It isn't a file agents parse. It is a search-first paradigm: instead of pre-loading every tool it might conceivably need, an agent asks, at runtime, what fits the task in front of it.

The refusal that makes it work#

Here is the design decision that let eleven rivals sign. ARD is not an execution protocol, and it goes out of its way not to become one.

Every catalog entry is what the spec calls an artifact-agnostic envelope. Each has a type field that is an IANA media type, and that field is the only thing a registry needs to understand. It tells the registry that this entry is an MCP server, or an A2A agent card, or an OpenAPI tool, or a nested sub-catalog — without ARD knowing one thing about that artifact's internal schema. An MCP server and an A2A agent can sit in the same list, described the same way, and neither protocol has to change to be listed.

ARD finds the resource, then gets out of the way. Discovery and invocation are deliberately split: once an agent has a match, it connects over the resource's own native protocol — MCP, A2A, REST — and ARD is done.

That is why it doesn't compete with MCP or A2A, and why it doesn't collide with the cloud agent registries that shipped this spring, either. MCP is how you call a tool. A2A is how you call another agent. ARD is the layer before the call. It's the yellow pages, not the phone line.

Why this is a different question than the MCP registry answered#

The official MCP registry is a fine thing, but it answers a narrow question: where is the server named acme/postgres? You look it up by name and package metadata, the way you'd resolve an npm dependency. That works when you already know what you want.

ARD is built for the case where you don't. "What can issue a refund against our billing provider" is not a name lookup; it's a semantic search over capabilities that may live at a hundred domains you've never heard of. And because the manifest lives at a well-known path on the publisher's own domain, domain ownership doubles as cryptographic identity — controlling acme.com is the proof that this catalog entry is really Acme's. The verification the agent needs before it connects is baked into where the file lives, not bolted on afterward. The server-cards .well-known discovery work inside MCP was reaching for the same idea; ARD generalizes it above any single protocol.

The part the launch posts underplay#

None of this is deployed. ARD is a six-week-old draft. The reference implementation carries a couple dozen stars and a short list of open issues, and — the tell that matters most — neither Anthropic nor OpenAI, whose clients are where most agents actually run, has shipped client-side support. Google Cloud's Agent Registry implements it inside Gemini Enterprise, and Hugging Face wrapped its Hub search in an ARD envelope, but a spec that agents can't yet consume by default is a proposal wearing a standard's clothes.

Publishing an ai-catalog.json is cheap and forward-compatible, so there's little reason not to. Designing a product on the assumption that agents will find you through ARD is a different bet, and it's early to make it. The right posture is the one the good discovery standards earn slowly: ship the manifest, watch the clients, and don't confuse eleven signatures on a draft for the thing actually being wired into the runtime. The war over how agents discover each other isn't over. ARD is the first credible peace treaty — but a treaty is only as real as the armies that honor it.