Agentic Resource Discovery Checker

Find and review the machine-readable information that helps AI agents discover a website's tools, services and capabilities.

Public websites only. Public endpoints only. The checker does not log in, execute tools or verify bot identity.
Based on the public ARD proposal. The results are practical diagnostics, not official conformance certification or a Google AI ranking score.

What the checker examines

An ARD file is more than a list of links. Its entries describe what a resource does, how to find it and which tasks it can help complete.

  1. Locate the public ARD manifest.
  2. Review required fields in each entry.
  3. Highlight missing natural-language discovery queries.
  4. Identify alternate discovery links and Agentmap hints.
  5. Explain improvements with the original proposal as reference.

What is Agentic Resource Discovery?

Agentic Resource Discovery (ARD) is an emerging approach to helping AI systems find capabilities they can use. An AI assistant might know how to answer questions, but completing a task often requires an external tool, API, workflow, specialist agent or MCP server. ARD provides a common way to describe these resources so discovery systems can identify relevant options.

Think of it as a directory that can be searched by what a capability does, rather than a list that someone must already know by name. ARD focuses on finding a capability. Connecting to it, gaining permission and carrying out the task are separate steps handled by the underlying service.

Why does ARD matter for AI search?

Conventional search primarily helps people find information. Agent-based search and task completion may also require locating services that can act on that information. For example, an assistant asked to compare a shipping quote may need to find a suitable pricing API before requesting prices. If that API is not discoverable, the assistant may never consider it.

ARD aims to make these capabilities discoverable across publishers and registries. Its connection to AI search is therefore strongest for tools and actions, not for the ranking of regular articles. Publishing an ARD manifest does not guarantee citations in AI-generated answers or higher search visibility.

How does ARD work?

1. Publish a resource description

A resource publisher describes each callable capability with a unique identifier, human-readable name, media type and either a URL or inline data. Practical entries also explain what the capability does and provide example questions or tasks.

2. Make the description discoverable

The specification identifies /.well-known/ai-catalog.json as its manifest location. The proposal also describes rel="ai-catalog" links and additional discovery mechanisms such as robots.txt Agentmap hints, in-page JSON-LD and DNS discovery. These mechanisms help discovery services locate resource descriptions.

3. Search a registry

Discovery registries can index descriptions and allow a client to ask which resource matches a task. The proposal distinguishes this active search layer from static manifest publishing. Not every implementation supports every discovery option.

4. Connect using the resource's native protocol

Once a resource is selected, the AI client uses the appropriate connection or invocation mechanism. ARD itself does not provide authentication, run tools or confirm safety.

What should an ARD manifest contain?

The published proposal requires each entry to provide an identifier, displayName, type, and exactly one of url or data. It recommends representativeQueries because real-world task descriptions make capabilities more searchable. Two to five example queries are recommended, not mandatory for structural validity.

The proposal uses JSON-LD concepts and allows additional namespaces through @context. For a useful implementation, clear descriptions, accurate ownership information and relevant capability labels are important. The example below illustrates the basic layout rather than a production-ready resource:

{"specVersion":"1.0","host":{"displayName":"Example"},"entries":[{"identifier":"urn:air:example.com:shipping-quotes","displayName":"Shipping Quote Service","type":"application/json","url":"https://example.com/api/shipping","description":"Provides shipping estimates for supported destinations.","representativeQueries":["Estimate delivery cost to Berlin","Get a shipping quote for a parcel"]}]}

How to improve your ARD discovery results

  1. Publish a valid manifest at the documented well-known path.
  2. Give each resource a stable identifier and an accurate media type.
  3. Use exactly one resource representation: URL or inline data.
  4. Write concise, specific descriptions that explain the action supported.
  5. Add realistic representative queries for the tasks people actually request.
  6. Ensure that URLs, permission requirements and resource ownership remain current.
  7. Review the official schema and conformance tools before making compliance claims.

Why crawler accessibility tests matter

A published catalog is helpful only when clients can retrieve it. The checker compares requests made with a browser-like header, common AI crawler names and a generic HTTP client. Different responses can indicate access controls, authentication requirements or an automated-traffic challenge. These are diagnostic comparisons, not verified tests of a crawler operator. A User-Agent header can be copied by anyone. Evaluate actual access using server logs, crawler verification, CDN settings and robots.txt.

How to read your report

A discovered manifest shows that a public source of ARD metadata is available. The entries count tells you how many descriptions were inspected, while structural issues identify missing required data. Suggestions cover discoverability improvements such as representative queries. A result with no structural issues is not a guarantee that an agent will find, trust or successfully use the resource.

If your website only publishes content and does not expose callable services, a missing ARD file may be entirely appropriate. For a broader assessment of crawler access and content availability, use the Site Agent Readiness Checker. For multiple agent protocols, see the Emerging Protocols Checker. You can also assess public crawler policies with the AI Crawlers Compatibility Checker.

What does did:web add to resource discovery?

A did:web identifier connects a decentralized identifier to a document published over HTTPS. For a root-domain identity, the expected location is /.well-known/did.json. This checker compares the published document identifier with the domain and checks basic document structure. A valid DID document is useful identity metadata, but it is optional for ARD and does not by itself prove ownership, authorization, or cryptographic trust. Read the did:web method specification for resolution and verification requirements.

How is ARD evolving?

ARD is currently a proposal, not an established universal requirement for websites. Its published draft specification places emphasis on JSON-LD-based descriptions, static discovery and searchable registries. The proposal's repository includes formal schemas and a conformance tester. Adoption, supported discovery channels and registry interoperability may change as the ecosystem develops.

Primary references

Frequently asked questions

ARD is an open proposal for describing, publishing and searching agentic resources such as MCP servers, AI agents, reusable skills and APIs. It focuses on finding a capability before using it.

Enter a public website domain or URL and run the scan. The checker checks /.well-known/ai-catalog.json and advertised alternatives, reviews resource entries, and compares public HTTP responses for several client headers.

A pass means the public manifest was found and the local structural checks did not identify a missing required field. It does not establish official conformance, reliability, security or successful invocation.

The expected discovery document was not found or could not be read. A business with no published agentic services may not need one.

It is a JSON document usually published at /.well-known/ai-catalog.json with an entries array describing discoverable capabilities.

The ARD proposal requires identifier, displayName, type and exactly one of url or data in an entry.

Representative queries describe tasks a user might ask an agent to perform. The specification recommends two to five queries so registries can match tasks to useful capabilities.

ARD describes its entry model using JSON-LD and extensible namespaces. Entries can use an @context for additional terms. This checker inspects JSON structure but does not perform full JSON-LD expansion.

MCP defines interactions with tools and resources. ARD is concerned with finding the appropriate published capability. Discovery comes before connection or execution.

Static discovery uses manifests and links hosted by publishers. Dynamic discovery relies on searchable registries that index entries and return relevant matches.

It is mainly useful when a site offers callable tools, agents, APIs or workflows. Informational publishers still benefit from crawl accessibility, structured content and clear entity information, but ARD is not a mandatory AI search optimization requirement.

There is no established evidence that publishing ARD metadata is a ranking factor for AI search answers. Its intended value is discovery of callable capabilities, not ordinary article ranking or citations.

No. robots.txt addresses crawler access preferences. llms.txt is a separate content guidance proposal. ARD advertises agentic resources and their discovery metadata.

It is a link relation used to advertise a resource discovery document from HTML or HTTP Link headers. The proposal also supports the ai-catalog well-known path.

The ARD proposal also describes an Agentmap directive in robots.txt and DNS service records as ways to signal sources of entries. Support and adoption remain evolving.

No. The tool does not verify signatures, attestations, ownership, permissions, or compliance assertions. Never assume a resource is safe simply because a descriptor exists.

The published specification identifies its status as Proposal. Its details and ecosystem support may change as implementations develop.

A server, CDN or firewall may serve different responses according to request headers, security challenges or other checks. This comparison uses descriptive User-Agent strings, not verified crawler identities.

No. Matching a user-agent string does not authenticate a bot and does not test the operators actual crawl infrastructure. Check robots.txt, security controls and access logs as well.

The public ARD proposal describes /.well-known/ai-catalog.json and rel=ai-catalog links. This checker also inspects advertised same-site URLs and robots.txt Agentmap hints.

The Emerging Protocols Checker broadly inspects various agent web standards and proposals. This tool examines ARD publishing and entry structure in greater detail.

Pass confirms the specific evidence observed, Review means optional information is missing or needs attention, and Fail indicates a core requirement is missing or malformed. The summary does not certify full ARD conformance.

No. A did:web document is useful optional identity metadata. This tool checks the domain DID document identifier and basic structure without cryptographic verification.

The current checker is configured for version 1.0. Other published version values are flagged for review because their field requirements may differ.