Agentic Resource Discovery (ARD): how AI agents find tools and APIs

By Nexscope Team · Published and reviewed October 15, 2026

Agentic Resource Discovery (ARD) is a new open proposal for the step that happens before an AI agent calls a tool: finding the right capability, comparing alternatives, and checking who published it. It is related to the broader AI-discovery conversation around GEO, but it is not a new GEO ranking algorithm.

Google announced ARD on June 17, 2026 as an open specification for publishing, discovering, and verifying AI capabilities across the web. The current public specification is version 0.91 and is marked Proposal, so names, paths, and conformance details may continue to change. Read Google’s announcement and the current ARD specification.

Key takeaways: ARD is for discovering callable resources; GEO is for visibility in generated answers; MCP and A2A handle execution or agent communication. ARD uses catalogs and registries, carries machine-readable discovery signals such as representative queries, and can pass trust metadata to the client. It can make a tool easier to find, but it cannot guarantee selection or use.

What is Agentic Resource Discovery?

ARD is a discovery and verification layer for AI agents. It gives a publisher a standard way to describe an agentic resource and gives registries a way to index and search those descriptions across organizational boundaries.

The resources can include an MCP server, an A2A agent, an agent skill, an OpenAPI tool, an ecommerce API, or another catalog. Instead of requiring a developer to install every possible capability in advance, an agent can search for a capability at runtime and then connect through that resource’s native protocol.

The idea is similar to web search, but the unit being discovered is not a blog post. It is a callable capability with a name, type, URL or embedded data, description, example queries, and optional trust or compliance metadata. The registry helps with discovery; the resource’s own protocol remains responsible for authentication and execution.

How does ARD work?

ARD uses two cooperating pieces: a catalog published by the provider and a registry that searches catalogs. The basic flow is:

  1. A provider publishes a machine-readable catalog under its own domain.
  2. A registry crawls or receives that catalog and indexes its entries.
  3. An agent submits a natural-language need, such as “find an ecommerce tool that can compare Amazon review complaints.”
  4. The registry returns matching resources with metadata the client can inspect or verify.
  5. The agent connects to the selected resource using MCP, A2A, HTTP, OpenAPI, or another native protocol.

Google’s launch description calls catalogs and registries the two primitives of ARD. It says catalogs establish a domain-backed publishing relationship, while registries act as search engines for the agentic web. Google’s architecture overview also describes a trust step before a client connects to a selected capability.

ARD therefore separates three decisions that are often mixed together:

Decision Responsible layer Example question
Discovery ARD catalog and registry Which tool can answer this need?
Trust and policy Publisher metadata, registry, and client Who owns it, and is it allowed?
Execution MCP, A2A, HTTP, OpenAPI, or another protocol How do I authenticate and call it?

What is inside an ARD entry?

An ARD entry is a structured description of one resource, not a marketing paragraph alone. The v0.91 specification requires an identifier, display name, media type, and exactly one of url or data. It recommends representativeQueries, because example user requests give a registry useful signals for semantic matching.

A simplified entry looks like this:

{
  "identifier": "urn:air:example.com:server:catalog",
  "displayName": "Example Catalog Server",
  "type": "application/mcp-server-card+json",
  "url": "https://example.com/mcp/catalog.json",
  "description": "Search product and review evidence for ecommerce decisions.",
  "capabilities": ["ProductSearch", "ReviewAnalysis"],
  "representativeQueries": [
    "find products with repeated complaints about battery life",
    "compare review evidence for two ecommerce listings"
  ]
}

The specification also describes optional terms such as version, updatedAt, tags, capabilities, and trustManifest. The important distinction is that a registry can use the entry to decide whether a resource is relevant before loading every tool description into the model’s context window.

Do not treat the example as a production template without checking the versioned schema. The ARD project explicitly distinguishes a general catalog entry from an ARD entry: an entry that omits discovery signals may still be a valid catalog listing, but it may not be discoverable through ARD search. See the entry requirements in the specification.

Is ARD a new form of GEO?

No. ARD and GEO are adjacent, but they optimize different objects. GEO, or Generative Engine Optimization, describes work intended to improve whether content is retrieved, cited, or summarized in AI-generated answers. The original GEO research paper introduced the term in 2023 as a visibility problem for content creators in generative engine responses. Read the original GEO paper.

ARD instead describes how an agent finds a capability it might invoke. A product guide can be highly visible in an AI answer without exposing an API. Conversely, an API can have an ARD entry and be discoverable to an agent without ranking for a consumer-facing question in Google or ChatGPT.

Question GEO ARD
What is being discovered? Pages, brands, entities, and evidence Tools, agents, skills, APIs, and workflows
Where does discovery happen? AI answers and retrieval pipelines ARD registries and catalog resolution
What is the output? A citation, mention, summary, or recommendation A resource description that a client may invoke
What does success mean? Accurate, useful visibility in an answer Relevant, verifiable capability discovery
Does it execute a tool? No No; execution remains native to the resource protocol

Calling ARD “GEO for tools” can be a useful analogy for a first explanation, but it should not be presented as an official definition. The safer technical description is an agent discovery protocol adjacent to AI search visibility.

How is ARD different from MCP, A2A, and AI Catalog?

ARD does not replace the protocols it discovers. It sits in front of them so a client can find a suitable resource before using it.

  • MCP: defines a structured way for a client to connect to servers and call tools. ARD can describe and expose an MCP resource to discovery, but it does not define the tool call itself.
  • A2A: supports communication between agents. ARD can list an A2A agent and its capabilities, but it does not replace the A2A task and message protocol.
  • Agent Skills: package instructions or capabilities for an agent. ARD can index a skill entry and use its representative queries for discovery.
  • AI Catalog: provides a publisher-facing catalog format. ARD adds discovery-oriented expectations and a registry/search model around agentic resources.

The terminology is still moving. Google’s June announcement describes publishing an ai-catalog.json file at a well-known path. The current v0.91 proposal defines /.well-known/ard.json and a rel="ard" link as the preferred ARD discovery mechanism, while retaining compatibility discussion for predecessor catalog names. Pin the specification version in your implementation notes and check the official repository before deploying.

Should an API or MCP provider publish an ARD manifest?

Publish an ARD manifest when you have a real callable resource and want compatible registries to find it. It is not necessary for an ordinary marketing website or a static blog, and it is not a substitute for an API reference page, authentication policy, or security review.

Before publishing, prepare this checklist:

  1. Name one stable resource. Give the entry a durable identifier, display name, version, owner domain, and canonical URL.
  2. Declare the artifact type. Use the media type required by the resource protocol, such as an MCP server card or an A2A agent card, and verify the current schema.
  3. Describe real capabilities. List the tasks the resource can complete, not every aspirational roadmap item.
  4. Write representative queries. Add two to five natural-language examples that a user would actually ask. These are discovery signals, not keyword-stuffing fields.
  5. Keep access boundaries explicit. State authentication, rate limits, supported markets, data freshness, credit use, and human approval requirements.
  6. Add trust evidence where appropriate. Use the versioned trust-manifest guidance for publisher identity, compliance, or provenance; do not invent a certification claim.
  7. Test the published file. Fetch it from the public domain, validate JSON and schema, verify URLs, and test a representative registry search if one supports the format.
  8. Monitor changes. Update the entry when the endpoint, version, capabilities, or access policy changes, and preserve a changelog for clients that cache results.

An entry can make a resource easier to compare, but it does not guarantee that a registry will crawl it, that a search will return it, or that an agent will invoke it. Treat discovery as one layer in a larger reliability and security system.

What does ARD mean for an ecommerce API provider?

ARD creates a possible discovery route for ecommerce capabilities, not a new ecommerce ranking factor. A provider could describe separate resources for product research, review analysis, SEO evidence, creative generation, or catalog validation, each with focused representative queries.

For example, Nexscope’s ecommerce MCP server and ecommerce APIs for AI agents explain how a client can use documented tools. Those pages are the human-facing documentation and safety boundary. An eventual ARD entry could point compatible registries toward the relevant resource, but this article does not claim that the current Nexscope endpoints are ARD-conformant or already listed in an ARD registry.

The same boundary applies to marketplace research. The TikTok Shop API guide explains documented research workflows; it does not turn a public research API into a TikTok Shop account-management or checkout integration. ARD can describe a callable research capability, but it cannot grant permissions that the underlying API does not provide.

What should teams do next?

Start with a versioned discovery brief before writing production code. Record the resource owner, canonical endpoint, protocol, supported tasks, example queries, trust requirements, and failure behavior. Then compare the current ARD schema with the actual resource and decide whether early participation is worth the maintenance cost.

A practical sequence is:

  1. Pick one stable MCP server, API, or agent rather than cataloging an entire platform.
  2. Read the current ARD proposal and note the exact manifest path and media types.
  3. Build a minimal entry from the official schema and validate it locally.
  4. Publish it under the owning domain only after reviewing authentication and abuse risks.
  5. Test discovery with a few task-shaped queries and inspect the returned metadata.
  6. Measure successful discovery, connection, invocation, errors, and human approvals separately.
  7. Revisit the implementation when the proposal or registry behavior changes.

Do not promise “ARD ranking,” “guaranteed agent traffic,” or “automatic MCP adoption.” The useful claim is narrower: a well-described and verifiable resource has a better chance of being understood by compatible discovery systems than an undocumented endpoint.

Frequently asked questions

What is Agentic Resource Discovery (ARD)?

ARD is an open proposal for publishing, discovering, searching, and verifying callable AI resources such as MCP servers, A2A agents, skills, APIs, and workflows. It is a discovery layer, not an execution protocol or marketplace.

Is ARD a new type of GEO?

No. GEO focuses on visibility of content and brands in AI-generated answers. ARD focuses on discovery of callable capabilities by AI agents. They are related but should not be treated as the same ranking system.

What is the difference between ARD and MCP?

MCP defines how a client connects to and calls tools. ARD describes how the client or a registry discovers that an MCP resource exists, understands its purpose, and checks publisher metadata before use.

Should every website publish an ard.json file?

No. ARD is mainly relevant to publishers of agents, MCP servers, skills, APIs, and other callable resources. The specification is still evolving, so follow a pinned version and its current conformance guidance.

Does ARD guarantee that an AI agent will use my tool?

No. Publishing a catalog can improve compatibility with discovery systems, but it does not guarantee crawling, ranking, trust approval, invocation, traffic, or revenue.

Sources

Last reviewed: 2026-10-15 · Maintained by the official Nexscope team · Editorial & evidence policy.

Keep exploring

More from Guides

Continue with another article in this collection.

Getting started with Nexscope ecommerce tools →TikTok Shop API Guide: Product, Creator, Video and Seller Research with Nexscope →
Need help?

Bring a real ecommerce question.

Ask how to use a Nexscope workflow, suggest an improvement, or report a reproducible problem through the right public channel.

Ask in Q&A →Suggest a workflow →Report a bug →

See community and support options →