Google and Microsoft Back Draft AI Agent Discovery Spec
▼ Summary
– Eleven companies, including Google, Microsoft, and GitHub, published the open Agentic Resource Discovery (ARD) specification to enable AI agents to find and verify tools and agents across the web.
– ARD solves a coordination problem by moving tool discovery from pre-wired connections to a runtime search step, using publisher-hosted ai-catalog.json files and registries that index them.
– Several contributors released same-day implementations, including GitHub’s agent finder for Copilot and Hugging Face’s Discover Tool, with Cisco connecting it to its AGNTCY Agent Directory.
– Google plans to integrate native ARD support into its Gemini Enterprise Agent Platform’s Agent Registry in the coming months, though this feature is not yet live.
– The v0.9 draft spec is open for changes, but its success depends on the development of registries that can crawl catalogs at scale, primarily benefiting companies publishing tools and agents.
Eleven major technology companies, including Google, Microsoft, GitHub, and Hugging Face, have jointly released the Agentic Resource Discovery (ARD) specification. This open standard defines how AI agents can locate, verify, and interact with tools, skills, and other agents across the internet.
The draft specification was published on June 17, accompanied by reference implementations from several contributors. Licensed under Apache 2.0, ARD builds upon the AI Catalog data model, which is maintained by a working group under the Linux Foundation. The full list of backers also includes Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow, and Snowflake.
The Core Problem ARD Solves
The specification addresses a fundamental coordination challenge. Currently, an AI agent must be manually configured to connect with each tool, MCP server, or API it intends to use. As organizations publish more capabilities, this pre-wiring approach becomes unsustainable.
ARD transforms discovery into a search step that happens at runtime. This change primarily impacts companies that publish tools and agents, rather than typical content websites for now.
How the Specification Works
ARD relies on two core components: catalogs and registries. An organization publishes a catalog file, named `ai-catalog.json`, hosted at a well-known path on its own domain. This file lists the tools, MCP servers, agents, or APIs the organization makes available.
Registries then crawl those catalogs, index them, and respond to discovery queries from agents using plain language. Because each catalog resides on its publisher’s domain, the specification uses domain ownership to verify authorship.
For production environments, publishers can attach trust metadata, allowing an agent or registry to confirm the publisher’s cryptographic identity before establishing a connection. Once a capability is selected, ARD hands off, and the agent connects directly using the tool’s native protocol.
Day-One Implementations
Several contributors shipped working tools based on the specification on the same day it was released. GitHub introduced agent finder, which enables Copilot to discover matching MCP servers, skills, tools, and agents from a chosen registry, with users retaining control over what gets connected.
Hugging Face released a Discover Tool that searches skills and MCP servers across ARD services. Cisco integrated the spec with its AGNTCY Agent Directory, an open source project under the Linux Foundation.
This release continues a pattern of open specifications targeting the machine-readable layer of the web. Just two days earlier, Google published the Open Knowledge Format, a spec for sharing organizational knowledge between AI systems. The underlying approach is consistent across these efforts. Each asks you to publish a structured file under your own domain so AI systems can consume what you expose, without requiring manual wiring.
Google’s Role
Google’s contribution centers on Agent Registry, a component of its Gemini Enterprise Agent Platform. The company stated that Agent Registry will host and search agentic resources while handling enterprise governance. Native ARD support within the platform is planned for the coming months. Google said this would allow organizations to connect internal registries to the broader network. That support is not yet live, and ARD is a specification rather than a Google Search feature.
Why This Matters
The relevance depends on what you publish. ARD is designed for publishers of callable capabilities, the APIs, MCP servers, and agents that software connects to. A company that publishes tools now has a clear method for being discovered and trusted by agents. A typical content website has no immediate action to take.
The value of this effort is debated. Google’s John Mueller has argued that LLM systems cannot use files like `llms.txt` to differentiate one site from another, and he has advised focusing on current needs rather than future agent-oriented strategies. Since ARD targets tools and agents, not content, questions arise about building now for systems that may or may not generate traffic later.
What Comes Next
The specification is a v0.9 draft, and the contributors are inviting feedback and changes through the project’s GitHub repository. Its ultimate reach depends on registries that can crawl and index catalogs at scale, and that ecosystem is still in its early stages. Google’s Agent Registry support is months away.
If that network materializes, the primary advantage goes to companies offering tools and agents that others need. The early agentic-web features from Google hint at this direction. The immediate concern is whether your current platforms and tools will adopt ARD and what they will require you to publish.
(Source: Search Engine Journal)