Agentic Resource Discovery: A Search Engine for AI Tools

On June 17, eleven companies published a draft specification for how AI agents find tools. It’s called Agentic Resource Discovery, ARD for short, and the announcements came with the usual partner wall: Google, Microsoft, GitHub, Hugging Face, Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow, and Snowflake. Google’s own post frames it as supplying “the missing layer of the agentic web.”

Here’s why it’s on our radar, and probably should be on yours, even though Search Engine Journal’s read is that a typical content site has no clear action to take today. The architecture is the same shape as the search. A publisher describes what it offers, a crawler indexes it, a ranking system matches it to intent. We spent the last two years learning how that pipeline decides whether your content gets cited. ARD points the same pipeline at tools, skills, and agents. The lessons mostly transfer. So do the failure modes.

Let me walk through what it actually is, what shipped versus what’s a press release, and what, if anything, you should do about it.

What ARD is, in plain English

The problem ARD is trying to solve is real and easy to state. Today, an agent can only use tools that someone wired into it ahead of time. Microsoft’s Ramanathan Guha put the bottleneck bluntly on the company’s blog: an agent can only use what it’s been explicitly wired to use, and everything else may as well not exist. Microsoft’s post describes a fresh coding-agent install seeing a small built-in set, a power user wiring in a few dozen more, and the actual ecosystem of available tools numbering in the hundreds of thousands. The gap between what an agent can see and what’s out there is enormous.

ARD closes that gap with a discovery layer. Per Google’s announcement, the spec defines two pieces.

A catalog is a static file — ai-catalog.json, that an organization hosts at a well-known path on its own domain. It describes the organization’s capabilities, and because it lives in that domain, Google says that domain ownership serves as the cryptographic foundation for identity and trust. You are who you are because you control the domain the catalog sits on.

A registry is, in Google’s own words, a search engine for the agentic web. It crawls catalogs, indexes them, and makes them searchable. The Hugging Face implementation shows the shape of the query in practice, natural-language requests like “fine-tune a language model” or “transcribe some audio” returning ranked matches. The registry hands back what the agent needs to verify the publisher and connect.

Then ARD gets out of the way. Per Google, it sits before invocation: once the agent has selected a capability and verified the publisher, it connects directly using whatever native protocol the tool speaks, MCP, A2A, REST, and ARD is no longer in the path. It’s a matchmaker, not a middleman.

The analogy the launch posts reach for is the early web, and it’s worth borrowing because it’s the clearest way in. Microsoft’s post tells it directly: millions of pages existed but most stayed dark until search engines built a discovery layer that could reach everything and match it to need. Hand-curated directories couldn’t keep up. Search lit the web up. ARD is trying to be that layer for agent capabilities.

What actually shipped, and what’s a press release

This is where precision matters, because a coordinated eleven-logo launch makes a thing look more finished than it is.

What’s real today: the spec itself, published under Apache 2.0 and built on the Linux Foundation’s AI Catalog data model. Search Engine Journal is explicit that it’s a v0.9 draft, and that the contributors are inviting changes through the project’s GitHub repository. Drafts change.

The working reference implementations: Hugging Face shipped its Discover Tool, which by its own description wraps the Hub’s existing semantic search over Spaces, Skills, and MCP servers in the ARD envelope, built into the Hugging Face CLI with a live search endpoint. GitHub shipped agent finder, which SEJ reports lets Copilot discover matching MCP servers, skills, tools, and agents from a chosen registry, with users controlling what gets connected. SEJ also notes Cisco tied the spec to its AGNTCY Agent Directory. So this is more than a paper standard on day one — several contributors shipped working code.

What’s “coming months”: Google says native ARD support in its Gemini Enterprise Agent Platform Agent Registry is planned for later, and SEJ confirms that support is not live yet. Snowflake’s own post is written almost entirely in the conditional — “we envision,” “Snowflake could register,” “here’s what this could look like.” That’s not a knock; it’s an honest description of a spec that’s days old. But read those parts for what they are: roadmap, not shipping product.

So the honest state of things: a v0.9 draft, several real implementations that mostly index their own ecosystems so far, and enterprise vendors describing what they intend to build. SEJ’s framing is that the spec’s reach depends on registries that can crawl and index catalogs at scale, and that ecosystem is still in its early stages. A respectable launch. Not an ecosystem yet.

Why this exists (and why ordinary search couldn’t do it)

Traditional search worked because the web already had a common structure. Pages linked to other pages, HTML described content in a format crawlers could understand, and HTTP provided a standard way to access it. Search engines didn’t create that foundation—they built on top of it.

Tools and AI agents don’t have that same discoverable layer. For an agent to use a tool safely, it needs more than a name and a URL. It needs structured information about what the tool does, when to use it, who operates it, what inputs it requires, and what permissions it needs. Without a standard way to describe those details, discovery depends on manual integrations and private directories that don’t scale.

That’s the problem ARD is trying to solve. It creates a standardized way for tools and capabilities to describe themselves so agents can find and evaluate them automatically.

One important difference from traditional search is that ARD doesn’t rely on a single global index. Any organization can run its own registry, and registries can combine public, private, and vendor-specific tools into a single discovery layer. That means discoverability won’t depend on ranking in one dominant index. Instead, it will depend on which registries choose to index your catalog and how they rank results.

The part that should sound familiar

Here’s the reframe that makes ARD worth an SEO team’s attention.

Map the pieces onto things you already optimize for. The ai-catalog.json Manifest is the page, the thing you publish and control. The registry is the crawler and the index. The natural-language search the agent runs is for query intent. Ranking inside the registry is, well, ranking. Domain ownership as the identity anchor is a cryptographic version of the domain-level trust you’ve worked with for years.

We’ve watched a version of this movie. Our AEO post laid out the AI search pipeline: a query fans out into sub-queries, which retrieve chunks, which get reranked, which get grounded into an answer that cites some sources and mentions some brands. ARD is a similar skeleton with the nouns swapped. A task becomes a discovery query. A registry retrieves candidate capabilities. Something ranks them. The agent picks. The structural insight that carried AEO carries here too: you’re not optimizing for the request the human typed. You’re optimizing for the machine-generated query issued on their behalf. In AEO, that was the fan-out. In ARD, it’s the agent’s plain-language intent string hitting a registry’s search endpoint.

There’s one concrete detail worth pulling out, because it’s the closest thing to a published ranking signal. The spec includes a representativeQueries field, sample phrasings of the tasks a tool handles. Synscribe, walking through the spec, calls this field essentially keyword research for the agentic web: registries use those sample phrasings to build the embeddings they rank against, so a vague request lands on your tool because your catalog said, in effect, “this is the kind of thing I’m for.” Synscribe’s blunt version: craft them poorly, and your entry gets buried; craft them well, and you get selected at runtime over competitors. If that sounds like writing intent-matched copy so a retrieval system can find you, it’s the same muscle. Describe the job in the words people actually use.

So if you’re the kind of team that thinks about how machines parse and rank what you publish, ARD is that discipline applied to a new object. That’s the real reason to read it.

What this means for content and discoverability teams

Three honest takeaways, scaled to how early this is.

1. Most publishers don’t need to act yet

Most of your audience isn’t directly affected yet, and that’s not me being cautious; it’s what the trade press says. SEJ states it plainly: ARD is for publishers of callable capabilities, the APIs, MCP servers, and agents that software connects to — and a typical content site has no clear action to take today. If you publish content rather than callable resources, there’s nothing to put in an ai-catalog.json. The publishers who care first are SaaS platforms, dev-tool companies, anyone whose product is something an agent would invoke rather than read. Google says publishing a catalog takes “minutes” via the quickstart guide; if that’s you, the action is concrete. If it’s not you, this is “understand the shape, watch the space,” not a to-do.

2. Don’t treat AI manifests as a ranking shortcut

Resist the urge to treat ai-catalog.json as the next file to rush out the door, and note that Google’s own John Mueller has voiced the matching skepticism. SEJ reports Mueller arguing that LLM systems can’t use files like llms.txt to distinguish one site from another, and advising teams to focus on current needs rather than future agent-oriented strategies. That’s not a statement about ARD specifically, but it’s the same caution: a structured file you publish for AI systems is not automatically a lever that moves outcomes. We’ve seen this before with llms.txt, as covered in our own AEO write-up, a roughly 300,000-domain analysis found no correlation between having an llms.txt file and AI citation frequency, with adoption around 10%. ARD’s manifest is more substantive than a hint file. But publish a catalog because you ship callable resources and want to be an early participant, not because a post told you it’s the new ranking lever.

3. Domain authority becomes domain identity

Per Google, in ARD, your domain isn’t one trust signal among many; ownership of it is the cryptographic foundation for identity and trust. The catalog is trusted because you demonstrably control the domain it’s served from. That’s a quiet escalation of something SEO has always cared about, and it rewards the same boring fundamentals: a clean, controlled, authoritative domain presence.

Why Agentic Resource Discovery Isn’t a Mature Ecosystem Yet

Now, the part of the launch posts soft-pedal, and the reason we’d hold the excitement loosely.

Adoption is the whole ballgame, and it’s early

A discovery layer is worth exactly as much as the number of agents querying it and the number of catalogs it can find. SEJ’s assessment is that the spec’s reach depends on registries crawling and indexing catalogs at scale, and that ecosystem is still in its early stages. Google’s enterprise support is months out. For contrast, MCP got real through broad adoption: by one industry tally, it passed tens of thousands of public servers and tens of millions of monthly SDK downloads, and was taken up by the major AI clients. That’s the bar. ARD hasn’t cleared it yet, because it just started.

There’s no measurement layer

This should sound familiar from the Siri situation we wrote about. A new surface is only as manageable as your ability to see yourself on it. Nothing in the announcements describes a “registry console”, a report telling you how often your catalog was returned, ranked, or selected, or an equivalent of impressions. If you publish a catalog today, you’re publishing into the dark. Set stakeholder expectations before someone asks you for an ARD visibility dashboard that, for now, can’t be built.

Discovery isn’t selection

Being in a registry is not the same as being chosen by the agent. This is exactly Synscribe’s central critique: ARD addresses what happens after an agent decides to query a registry, and per their framing, the registry is one step in a longer sequence, train, search, fetch, environment, registry, with most of the selection happening before a registry is ever queried. “Get listed” is the easy part. “Get picked” is the part nobody can hand you a playbook for yet.

Training data still shapes outcomes

Synscribe’s research argues that an agent frequently answers from its training memory before it ever runs a discovery query: in their analysis, agents in mid-2026 were operating on a roughly five-month-stale training prior and confidently recommending incumbents that were well-represented in training data, and, in their words, publishing an ai-catalog.json won’t fix that, because nothing in ARD touches your training presence. Treat that as one agency’s finding rather than a settled fact, but the logic is hard to dismiss, and it’s specific to exactly the citation-and-mention game our readers play. ARD can make you discoverable. It can’t make a model ask in the first place.

ARD is not the entire AI ecosystem

It’s worth noting who’s not on the list: OpenAI and Anthropic. Outlets including Cryptobriefing and The Information read ARD as partly a competitive move by the enterprise-software incumbents, a world where agents automatically find Google Workspace, Microsoft 365, and Salesforce, is a world that favors the companies that wrote the spec. That doesn’t make ARD bad; Apache-licensed and open is Apache-licensed and open. But the two companies behind ChatGPT and Claude, the surfaces where a lot of your AI visibility lives, sat this one out. Treat ARD as an important enterprise-tooling standard, not as the thing that governs whether ChatGPT cites you next month.

Where this leaves you

Short, because there isn’t much to do, and pretending otherwise would be the exact thing we keep warning against.

If your product is a callable capability, an MCP server, an API, or an agent, read the spec and consider publishing a catalog. Google says it’s a few minutes of work, and being an early, verifiable participant costs little. Just go in knowing you’re publishing into a surface with no measurement and an early-stage ecosystem, and don’t build a forecast on it.

If you publish content rather than capabilities, SEJ’s read is that there’s no clear action this week, and that’s fine. There’s a concept worth internalizing: the discovery pipeline you’ve spent two years learning for AI search is now being pointed at tools, and the same instincts that describe the job in real language, control a clean, authoritative domain, structure things so machines can parse them, are the ones that transfer when it matters. File this under “understood,” not “implemented.”

And whoever you are, hold the open questions open. Whether ARD gets adopted, whether registries develop real ranking signals, whether agents query them before falling back on training memory, these are genuinely undecided. The teams that come out ahead won’t be the ones who shipped a catalog fastest. They’ll be the ones who could tell the difference between a standard that’s been announced and one that’s actually running, and who spent their energy accordingly.

See where you stand on the surfaces you can measure

ARD is a surface you can’t measure yet. Plenty of others you can. Quattr’s AI Search Visibility platform tracks your citation share, mentions, and brand gaps across AI Overviews, ChatGPT, and Perplexity, so the measurable surfaces stay measured while the new ones settle into something worth acting on.