ARD Gives Agents a Real Way to Find Tools

AI agents already know how to call tools. What they still struggle with is finding the right ones across team and company boundaries without a hardcoded list. That gap is why Agentic Resource Discovery (ARD) matters.

Google and a broad set of industry partners just published ARD as an open specification for publishing, discovering, and verifying AI capabilities on the open web. The partners include Microsoft, GitHub, Hugging Face, Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow, and Snowflake. The pitch is straightforward: agents need reliable answers to three questions at runtime. Where does the right capability live? Which one should they use? How do they verify it is safe to connect to?

ARD does not invent a new invocation protocol. It sits before MCP, A2A, OpenAPI, and similar execution layers. That design choice is the right one, and it is why this is more than another agent hype drop. Discovery was the missing layer. Whether ARD becomes plumbing or shelfware now hinges on catalog adoption and registry quality, not on the elegance of the schema.

The discovery hole protocols never filled

Protocols such as the Model Context Protocol define how an agent talks to a tool once it already knows the endpoint. That is necessary. It is not sufficient.

In practice, agent wiring still looks a lot like early web directories. Someone (or some config file) has to name every MCP server, OpenAPI surface, skill, or peer agent up front. Cross-org work makes that brittle. An ops agent handling a live incident might need observability queries, deploy history, runbooks, ticketing, and a specialized troubleshooting agent, each owned by a different team or vendor. Custom registries exist, but they stay siloed inside platforms. Interoperability suffers, and "find something that works" is not an enterprise answer.

Srinivas Krishnan, Distinguished Engineer at Google Cloud, put the enterprise constraint cleanly: the answer has to be governed, with security and identity built in rather than bolted on. ARD is Google and partners' attempt to standardize that earlier lifecycle stage without replacing the execution standards teams already ship.

Jennifer Marsman, Principal Engineer in AI at Microsoft, is also clear on scope: the goal is not one global catalog of every resource. There will be many discovery services, each defined by what it indexes, whom it serves, and how it ranks. ARD helps clients discover capabilities. It does not replace authentication, authorization, governance, or organizational trust decisions. That restraint is healthy. Standards that try to own the whole stack usually fail.

Catalogs, registries, and domain-backed trust

ARD rests on two primitives.

Catalogs. An organization publishes a machine-readable ai-catalog.json at a well-known path on its own domain. The file describes tools, APIs, skills, agent endpoints, MCP servers, A2A agents, OpenAPI surfaces, or nested catalogs. Hosting under the org's domain is not decoration. Domain ownership is the cryptographic foundation for identity and trust.

Registries. Registries act as search engines for agent capabilities. They crawl published catalogs, index contents, and answer discovery requests, including natural-language intent. Agents can also skip search and fetch a known partner's catalog directly. Either path should return enough metadata to verify the publisher before the client connects.

The intended flow is clean: publish under your domain, get indexed (or fetched directly), verify trust metadata, then hand off to the resource's native protocol for the actual call. ARD steps out of the way after discovery. That separation keeps the discovery layer thin and reusable across frameworks.

Trust and verification are central, not optional footnotes. Domain-based ownership plus verifiable trust metadata are meant to reduce the risk of autonomous agents wiring themselves to random third-party endpoints. In production, that verification step is the difference between useful federation and a supply-chain mess.

The specification is Apache 2.0 licensed and builds on the AI Catalog data model from the Linux Foundation's AI Catalog Working Group. Schemas, federation model, trust architecture, and reference implementations are already available for experimentation.

What developers should do with this now

If you ship tools, MCP servers, agent endpoints, or internal APIs that other agents might call, the practical first move is small: publish an ai-catalog.json for your domain and keep it accurate. Discovery quality will track catalog quality. A registry that indexes stale or vague entries will not help anyone.

If you build agent clients or orchestration layers, treat ARD as a discovery backend rather than a replacement for your auth stack:

• Query a registry with task intent, or resolve a partner catalog directly when the relationship is known.
• Verify publisher identity and trust metadata before loading anything.
• Invoke through the native protocol already advertised (MCP, OpenAPI, A2A, etc.).
• Keep org policy on egress, allowlists, pricing, and data residency in your control plane. ARD will not make those decisions for you.

Early surface area already exists. GitHub has Agent Finder in Copilot. Hugging Face has a Discover Tool that wraps Hub semantic search over Spaces, Skills, and MCP servers in the ARD envelope. Connection guides exist for major clients (Claude, ChatGPT, GitHub Copilot, Microsoft Copilot, Gemini). Google Cloud's Agent Registry in the Gemini Enterprise Agent Platform is positioned as an enterprise-grade node in a federated network, with namespaced URNs, egress policy, pinning, and cryptographic trust manifests (including compliance-oriented use cases such as HIPAA). Native ARD support there is still rolling out in the coming months, so do not assume it is live for every tenant today.

Trade-offs are real. Dynamic discovery only helps if enough high-quality catalogs exist. Access models and pricing still sit outside the discovery layer, so "found it" does not mean "can afford or is allowed to call it." Autonomous discovery also expands the attack surface if verification is weak or agents are over-privileged. Teams that already maintain private tool registries will need a clear federation policy: what leaves the org boundary, what stays internal, and which external registries are trusted.

For platform engineers, the useful near-term experiment is internal: publish catalogs for shared internal tools, stand up or evaluate a registry, and measure whether agents can resolve capabilities by intent without config churn. Cross-org federation can wait until trust and policy knobs feel solid.

Open plumbing, platform gravity

On paper, ARD is federated. Many registries, no single global catalog, crawl-and-index rather than central gatekeeping. That is the right architecture for an agentic web.

In practice, registry operators will hold a lot of power. Ranking, indexing scope, and trust signals shape what agents "see." Google Cloud's hosted Agent Registry is an obvious path of least resistance for enterprises already on that stack. Hugging Face's Discover Tool shows the open Hub side of the same idea. Competitive independent registries will need real catalog density to matter.

The partner list is strong on cloud, data, and developer platforms. Notably, OpenAI and Anthropic are not named among the launch contributors. That does not kill the standard, but it does mean client-side support and catalog publishing habits will decide whether ARD becomes shared infrastructure or a Google-Microsoft-centric orbit with optional hangers-on.

Community discussion already lands on a fair point: a uniform baseline beats proprietary documentation formats and one-off scrapers. Effectiveness still depends on the quality of exposed tools and the commercial terms around them. Specs do not invent good tools.

Worth building against, if catalogs show up

ARD is a genuine shift in the shape of the problem, not a finished ecosystem. It correctly separates discovery from invocation, roots identity in domain ownership, and leaves room for many registries instead of one marketplace. That is solid engineering judgment for a multi-agent world that will not live inside a single vendor's control plane.

For working developers, the decision is pragmatic. Publish catalogs for anything you want agents to find. Wire clients to verify before connect. Keep auth, policy, and spend controls outside ARD. Watch whether enough organizations actually host ai-catalog.json files to make registry queries worth the latency and complexity.

If federation gets real catalog density over the next year, ARD becomes boring infrastructure in the best way: the search layer agents needed so MCP and friends can stop assuming every endpoint was known at deploy time. If catalogs stay sparse, it remains a well-designed draft with reference demos. The protocol is ready enough to experiment with. The network effect is not automatic.