Eleven Rivals Just Agreed on How AI Agents Find Tools: Inside the ARD Spec

TL;DR

On June 17, a coalition of eleven normally-competing companies (Microsoft, Google, Nvidia, Hugging Face, GitHub, Cisco, Databricks, GoDaddy, Salesforce, ServiceNow, and Snowflake) published Agentic Resource Discovery (ARD), an open, Apache-2.0 specification for how AI agents find, rank, and verify tools across the open web. MCP told an agent how to call a tool it already knew about. A2A told two agents how to talk. Neither answered the prior question: how does an agent find the right tool in the first place, and trust it before connecting? ARD is that missing discovery layer. You publish a single ai-catalog.json at a well-known path on your own domain, registries crawl and index it like a search engine, and agents query in natural language and get back ranked, verifiable matches. It is still v0.9 draft, but the signatory list is the actual story.

The gap nobody had standardized

2025 and early 2026 gave agent builders two real protocols. MCP standardized the wire format between a model and a tool. A2A standardized agent-to-agent messaging. Both assume you already have the endpoint in hand. In practice you hard-coded it, or pre-installed a bundle of MCP servers, or pasted a registry URL into a config and hoped it stayed alive.

That is the bottleneck ARD names directly. Its authors frame three unanswered questions an autonomous agent hits the moment it needs a capability it was not shipped with: where does that capability exist, which of several candidates should it use, and how does it verify the thing is safe before it connects. Today every vendor answers those inside its own walled registry, so an agent on one platform is blind to tools published on another. ARD's pitch, in its own words: "Just as the open web democratized information, ARD democratizes AI resource discovery."

How it works: catalogs and registries

The spec is deliberately small. It defines two primitives, and they map almost exactly onto how the human web already works.

Catalogs (your sitemap)

You describe what you offer in a manifest and host it on your own domain at a well-known path:

https://yourcompany.com/.well-known/ai-catalog.json

That file lists your resources and, critically, what each one is: an MCP server, an A2A agent card, an OpenAPI tool, a Skill, or even a nested catalog pointing elsewhere. Each entry carries structured metadata: what it does, when to use it, accepted inputs, the authority it requires, who operates it, and how to invoke it. Because the manifest lives under your domain, domain ownership becomes the cryptographic trust anchor. If it is served from stripe.com, you have a verifiable signal it is actually from Stripe, not a look-alike.

Registries (the search engine)

A registry crawls published catalogs, indexes them, and answers discovery queries. An agent sends a natural-language request ("I need to refund a payment") and gets back ranked candidates plus verification metadata, rather than a raw dump the model has to read into its context window. Hugging Face's implementation notes it ranks on "richer signals such as publisher identity, representative queries, compliance attestations, and tags," not just embedding similarity. Registries are federated, so no single company owns the index. Think robots.txt and sitemaps feeding a crawler, except the crawler serves agents.

It sits in front of MCP and A2A, not against them

This is the part worth internalizing. ARD does not replace anything you have already wired up. It is the layer that lets an agent discover an MCP server or an A2A agent at runtime instead of being pre-loaded with it. The catalog entry literally points at your existing MCP endpoint or agent card. Hugging Face describes ARD as "the discovery layer that sits in front of" MCP, Skills, and A2A, enabling agents to find capabilities dynamically rather than requiring pre-installation. The whole thing is built on the AI Catalog data model from the Linux Foundation's AI Catalog Working Group, so it is not a single vendor's land grab dressed up as a standard.

Why the signatory list is the real headline

Specs are cheap. A spec that Microsoft, Google, Nvidia, Salesforce, Snowflake, Databricks, ServiceNow, Cisco, GitHub, GoDaddy, and Hugging Face all put their name on the same week is not. These are companies that compete hard on agent platforms, and they agreed on the discovery layer rather than each shipping an incompatible registry. That is the pattern that made MCP stick, happening again one rung up the stack.

It helps that the lead author is Ramanathan Guha, now a Microsoft Technical Fellow, the same person behind RSS, RDF, sitemaps, and Schema.org. The man who spent two decades standardizing how the web publishes machine-readable metadata is now doing it for agents. Google Cloud is already backing the spec with an Agent Registry product in its Gemini Enterprise Agent Platform, complete with namespaced URNs, egress policies, and cryptographic trust manifests.

What you can actually touch today

This is a v0.9 draft, but it is not vaporware. Hugging Face shipped a reference implementation, the "Discover Tool," on launch day. Its catalog is live:

https://huggingface.co/.well-known/ai-catalog.json

The Discover Tool wraps Hugging Face Spaces as Skills or MCP server entries depending on what the calling client asks for, and exposes both a search endpoint and an MCP endpoint so an agent can find and call in one flow. The spec itself lives in the open at github.com/ards-project/ard-spec under the ards-project org, rendered at agenticresourcediscovery.org, and it is taking issues and pull requests. If you operate any tool an agent might want, publishing a catalog is a static JSON file and a well-known path. That is a low enough bar to do this weekend.

The honest caveats

• It is v0.9. The data shapes can still change. Do not hard-code against it as if it were frozen.
• A spec is not an ecosystem. Discovery only matters once enough catalogs exist and enough registries crawl them. Right now that is mostly Hugging Face plus Google Cloud's hosted registry. The flywheel has to spin.
• Trust is anchored to domains, not audited behavior. Domain ownership proves who published a tool, not that the tool is safe or does what its metadata claims. Verification metadata and compliance attestations help, but an agent still needs its own guardrails before it connects to something it discovered.
• Notable absences. Anthropic, the company that authored MCP, is not on the signatory list, and neither is OpenAI. A discovery standard for the agentic web is stronger with them than without.

Key Takeaways

• ARD launched June 17, 2026 as an Apache-2.0 open spec for agents to discover and verify tools across the web.
• Two primitives: catalogs (an ai-catalog.json at /.well-known/ on your domain) and federated registries that crawl, index, and answer natural-language queries.
• It complements MCP and A2A. It is the find-and-trust layer in front of them, not a replacement; catalog entries point at your existing MCP servers and agent cards.
• Eleven competing vendors signed on (Microsoft, Google, Nvidia, Hugging Face, GitHub, Cisco, Databricks, GoDaddy, Salesforce, ServiceNow, Snowflake), with RSS and Schema.org creator Ramanathan Guha as lead author.
• You can ship today: Hugging Face's live catalog and "Discover Tool" reference implementation are out, and publishing your own catalog is one static JSON file.
• Watch the gaps: still v0.9, the registry ecosystem is young, trust is domain-anchored rather than behavior-audited, and Anthropic and OpenAI are not yet in.

Sources: Google Developers Blog, Microsoft Command Line, Hugging Face, ards-project/ard-spec on GitHub, Help Net Security.