Google ARD Explained: AI Agent Discovery, Trust, and MCP

Recently Google Cloud published the Agentic Resource Discovery (ARD) spec, and if you’ve spent any time building agents that call MCP servers or talk to other agents, the problem it’s solving will sound a little familiar. You know that the tool exists. You don’t know where it lives, whether the version you found is current or whether you can trust whoever’s running it. Right now every platform answers that with its own registry, and none of them talk to each other.

What Problem Is ARD Actually Solving?

Let’s say you’re running an ops agent that needs to pull logs from an observability platform, check a deployment history, and maybe hand off to a specialized troubleshooting agent from another team. Today, that means hardcoding endpoints, or building custom lookup logic for each vendor’s proprietary catalog. Nothing about this scales past a handful of integrations.

ARD’s answer is to treat discovery the way the web treats search: capabilities get published under an organization’s own domain, and registries crawl and index them the way search engines crawl pages. Domain ownership becomes the root of trust: the same logic behind SSL certs and DNS-based verification, got applied to “can I trust this MCP server before I connect to it.“

Catalogs and Registries: The Two Moving Parts

The whole spec really comes down to two things.

A Catalog is a JSON file “ai-catalog.json” that a provider hosts at a well-known path on their own domain. It lists what’s available: MCP servers, A2A agents, OpenAPI tools, even other catalogs nested inside it. Because it lives on your domain, anyone who finds it already knows who’s vouching for it.

A Registry is what actually crawls and indexes those catalogs, and it’s what an agent queries when it needs to find something. You can either send a registry a plain-language request: “I need something that reads Datadog logs” or skip search entirely and pull a known partner’s catalog directly if you already know the domain.

That second path matters more than it might seem. Search is good for the open-ended case, but a lot of real agent workflows involve known partners: your own internal teams, a vendor you already have a contract with, a specific org you trust. ARD lets you skip the registry entirely in those cases and fetch the catalog straight from the source, which cuts out a hop and a dependency on whichever registry happens to have crawled that provider recently.

Figure 1: Google ARD in action

Once a match is found, the registry hands over verifiable trust metadata and steps out of the way entirely. The agent connects directly to the provider using whatever protocol that tool natively speaks: MCP, A2A, plain REST, doesn’t matter. ARD isn’t trying to replace any of those. It’s solving the step before them: “How did you find this thing, and should you trust it?”

ARD vs. MCP: Where Each One Actually Fits

I think this is the part that would trip people up the most, so let’s be blunt about it: ARD and MCP are not competitors. MCP defines how an agent talks to a tool once it’s connected. ARD defines how an agent finds that tool and decides it’s safe to connect to in the first place. One’s a phone call, the other’s the phone book plus a background check.

Put them together and your workflow looks like: your agent queries an ARD registry for “something that manages Kubernetes deployments,” gets back three matching MCP servers along with cryptographic proof of who’s running each one, picks the one it trusts, and connects using standard MCP. ARD never touches the actual tool call. It just gets your agent to the front door and confirms the building is real.

Right now, if you want your agent to discover MCP servers outside your own org, you’re either maintaining a manual allowlist or trusting whatever a third-party aggregator tells you. Neither scales, and neither gives you a real answer to “is this actually who it claims to be.” ARD is explicitly trying to close that gap using domain ownership instead of another centralized platform you have to trust.

What This Means for Teams Already Building on MCP or A2A

If you’re already deep into MCP or A2A, nothing here forces a rewrite. Your servers and agents keep speaking whatever protocol they already speak, “ARD sits above that layer, not inside it”. The practical shift is in how discovery happens once this rolls out further: instead of manually wiring up every integration your agent needs, you’d publish (or consume) a catalog and let the registry layer handle matching.

Take that ops agent example again. Today, wiring it up to a new team’s troubleshooting agent probably means a Slack message asking for an endpoint, some manual auth setup, and hoping nobody rotates the credentials without telling you. Under ARD, that team publishes their agent in a catalog once, your registry indexes it, and your ops agent finds it the next time it needs it, no ticket required, and you get cryptographic confirmation it’s actually their agent before you connect.

This is early, and it’s worth being honest about that. Google’s own implementation, Agent Registry inside Gemini Enterprise Agent Platform, is live now for hosted search and cataloging, but native ARD support for connecting external registries to the broader federated network is still coming “in the coming months,” per the announcement. Authenticated publisher onboarding isn’t live yet either. So if you’re evaluating this for production today, you’re evaluating an early spec with one major implementation behind it, not a mature ecosystem with several competing registries that have been stress-tested against each other. That’ll likely change fast, given who’s backing it, but it hasn’t happened yet and I’d hold off on betting mission-critical discovery on it until a second or third registry shows up in the wild.

Getting Started (If You Want to Try It Now)

The lowest-effort way is publishing a catalog. If you’ve already got MCP servers or agents running, the quickstart guide walks through hosting an ai-catalog.json on your domain, which is a small enough lift that you could realistically do it in an afternoon. From there, the spec itself (schemas, federation model, trust architecture, reference implementations) is documented publicly, and the GitHub repo is where you’d file issues or propose changes before the format solidifies further.

It’s Apache 2.0 licensed and still actively changing, so if agent discovery is already a problem for you, now’s a decent time to poke at it and file an issue if something’s missing, rather than finding out later the spec settled without your use case in mind.