Agentic Resource Discovery: publish one file that tells agents what you offer.

Agentic Resource Discovery (ARD) is a way to publish, on your own domain, a machine-readable list of the agents, tools and servers you offer. An agent fetches one file, reads the entries, and follows each entry’s URL to the resource’s real description: an MCP Server Card, an A2A agent card, an OpenAPI document. The specification calls itself an envelope, not an execution mechanism.

Four facts to get right before you build anything:

1. ARD’s path changed. ARD v0.91, dated 26 August 2026, specifies /.well-known/ard.json. ARD names /.well-known/ai-catalog.json as its predecessor path. Nearly every explainer published between June and August 2026 describes the old path.
2. ai-catalog.json is still alive, under a different owner. It is the well-known path of the AI Catalog, a separate draft specification. On 6 October 2026, MCP merged its Server Cards proposal (SEP-2127) with the status “Final”, and that proposal points domain-level discovery at /.well-known/ai-catalog.json. So “predecessor” is ARD’s view of the file, not the whole story. The next section explains how the two relate.
3. Neither is a finished standard. ARD’s header reads “Status: Proposal” and there is no v1.0. The AI Catalog’s published specification says “This is a draft document and may be updated at any time.” Neither is a W3C or IETF standard.
4. Adoption is negligible so far. See the adoption section below for the one public measurement we could find.

First reviewed 1 September 2026 against ARD v0.91 in github.com/ards-project/ard-spec. Rechecked 8 October 2026 against ARD v0.91, SEP-2127 and the AI Catalog draft.

What is Agentic Resource Discovery?

ARD is an open specification for resource discovery, announced on 17 June 2026 in coordinated posts from Google, Microsoft, Hugging Face, Snowflake and Cisco. The spec names three authors: Junjie Bu (Google), R.V. Guha (Microsoft) and Shaun Smith (Hugging Face). A longer list of companies (GitHub, Cisco, Databricks, GoDaddy, Nvidia, Salesforce, Snowflake, Amazon among them) appears under Acknowledgements and on the project’s logo wall, as contributors rather than co-authors.

• Announcement: Google Developers Blog, “Announcing the Agentic Resource Discovery specification”, 17 June 2026
• Announcement: Microsoft, “Introducing the Agentic Resource Discovery specification”, 17 June 2026
• Announcement: Hugging Face, “Agentic Resource Discovery: Let agents search for tools, skills, and other agents”, 17 June 2026
• Later coverage: AWS, “Agentic Resource Discovery (ARD): An open specification for agent discovery”, 24 August 2026; InfoQ, 14 July 2026
• Canonical spec: agenticresourcediscovery.org/spec/, rendered from ards-project/ard-spec (Apache-2.0), which the docs site names as the single source of truth.

The problem it addresses is inversion of the registry. Today, if you build an MCP server or an agent, you publish it into someone’s catalogue (a marketplace, a registry, a directory), once per catalogue. ARD’s framing, in the spec’s own words, is that a publisher “describes a resource once on its own domain”, and existing collections “become ARD discovery services” that crawl those descriptions rather than acting as the place of record.

That is the same architectural move robots.txt and sitemap.xml made for search: the site owner publishes the assertion, and consumers come and read it.

Why does the well-known path say ard.json now?

Because ARD renamed and decoupled itself. The repository’s git history shows it began as “Agent Finder” and was rebranded to Agentic Resource Discovery on 11 June 2026, days before the public launch. Version 0.9 of the spec (28 May 2026) defined a manifest called ai-catalog.json; v0.91 (26 August 2026) defines an ARD entry that, per the spec’s own Appendix D, “does not derive from any catalog schema; the two evolve independently.”

The spec’s consumer rule is explicit, and it tells you how ARD readers treat the old path:

Consumer resolution (normative). A consumer resolving a domain’s entries MUST fetch /.well-known/ard.json, and MUST honour a rel="ard" link. ARD’s predecessor specified the path /.well-known/ai-catalog.json and the link relation ai-catalog; a consumer MAY additionally consult these […] a publisher on the predecessor path SHOULD move to ard.json.

So ARD consumers must read the new path and may read the old one. If you are starting today, publish ard.json. But do not read “predecessor” as “abandoned”: the same path is now the home of the AI Catalog, which MCP uses, and that is the subject of the next section.

One trap for anyone reading older manifests: the v0.9 catalogue format carried a top-level "specVersion": "1.0", and the current AI Catalog draft still requires that member. That string is the catalogue format version. It is not the ARD specification version, which is 0.91, and it does not mean the AI Catalog has reached a final 1.0 either. Do not read it as evidence that either specification is finished.

How do ard.json and ai-catalog.json relate?

They started as one effort and split into two specifications that still share most of their shape.

The AI Catalog lives in the Agent-Card/ai-catalog repository, created in October 2025, which describes itself as a temporary working repository maintained by the Linux Foundation, with members from the MCP and A2A communities. Its governance file lists four Technical Steering Committee seats, held by people at Google, Microsoft, Anthropic and PulseMCP. In July 2026 the AI Catalog group and the ARD group decided to stop sharing a data model. The AI Catalog’s decision record ADR-0017, “Loose Coupling of ARD and AI-Catalog”, agreed on 9 July 2026, records why: ARD wanted rich, namespaced metadata in each entry (JSON-LD @context, schema.org terms), while the AI Catalog wanted “a lightweight, strictly-typed ‘thin pointer’ registry format”. ARD v0.91 followed on 26 August with its own entry definition and its own path.

The overlap is deliberate. ARD’s §4 puts it in one line: “every ARD entry is a well-formed catalog entry, but not every catalog entry is an ARD entry.” In practice that means one list of resources can produce both files. Add a specVersion to make the AI Catalog version; keep displayName and representativeQueries in each entry to make the ARD version.

What are MCP Server Cards?

A Server Card is a small, static JSON document that describes one remote MCP server before a client connects to it: its name, version and description, its endpoints and transports, and the protocol versions it supports. It deliberately does not list tools, resources or prompts, because those can change by user and session and are read live through the protocol. If a card and the live server/discover response disagree, clients should prefer the live values.

The proposal is SEP-2127, “MCP Server Cards - HTTP Server Discovery”. It was opened on 21 January 2026 and merged on 6 October 2026, and the MCP site now lists it as Final. Its discovery rules are short:

• Domain-level discovery goes through an AI Catalog. “For automated domain-level discovery, an AI Catalog can be published at /.well-known/ai-catalog.json.” An entry of type application/mcp-server-card+json either links to a card or carries it inline.
• The card itself can live anywhere. The catalogue entry gives its URL. MCP reserves <streamable-http-url>/server-card as the recommended location, so a server at https://example.com/mcp would serve its card at https://example.com/mcp/server-card.

Here is what that looks like for one server, following the extension’s discovery document:

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:docs-search",
      "type": "application/mcp-server-card+json",
      "url": "https://example.com/mcp/server-card"
    }
  ]
}

“Final” needs one qualification. SEP-2127 is a chartering document: it says the normative wire format lives in a separate extension repository, modelcontextprotocol/ext-server-card. On 8 October 2026 that repository’s README still described the work as “Experimental”, its discovery document was marked “Protocol Revision: draft”, and the Python and Go SDK reference implementations named in the SEP were open, unmerged pull requests. The SEP also says the extension may evolve after acceptance, with breaking changes requiring a new extension identifier. Treat the decision as made and the details as still moving.

How does ARD relate to llms.txt, AGENTS.md and MCP?

Less closely than the commentary suggests.

Against MCP, A2A and OpenAPI: it wraps them. The spec’s interoperability document answers this directly. Asked whether ARD replaces those protocols, it answers: “No. ARD is a discovery protocol (an envelope), not an execution mechanism. It wraps existing execution standards (like MCP, A2A, and OpenAPI) using standard and proposed IANA media types.” An ARD entry carries a type that is a media type (application/mcp-server-card+json, application/a2a-agent-card+json) and a url pointing at that document. The entry is a pointer with enough metadata to decide whether to follow it.

The spec also flags that those two media types are not yet formally registered: they are described as “de-facto community standards tracking towards formal registration”, with the caveat that “the format may change.”

Against A2A’s /.well-known/agent-card.json: it points at it, not over it. If you already publish an A2A agent card, an ARD entry references it. The two are complementary; ARD adds the inventory layer that lets a domain declare more than one resource.

Against llms.txt and AGENTS.md: the specification does not mention them. We grepped the spec and docs repositories; llms.txt appears once, incidentally, and AGENTS.md not at all. Any claim that ARD “supersedes llms.txt” is commentary, not spec text. Functionally they solve different problems: llms.txt indexes documentation for reading, AGENTS.md gives a coding agent working in a repository durable local instructions, and ARD inventories invocable resources. A site can reasonably publish all three.

How do I publish an ARD manifest?

Step 1: Inventory what you actually expose

List the resources on your domain that an agent could invoke or search: an MCP server, an A2A agent, a public API with an OpenAPI document, a search endpoint, a skill bundle. If the answer is “none”, ARD has little to offer you yet: publish a sitemap and an accurate documentation index first.

Step 2: Write one entry per resource

Four members are required by the spec (§4.2), and one pair is exclusive:

The specification’s own example entry, verbatim from §4.4:

{
  "identifier": "urn:air:acme.com:server:weather",
  "displayName": "Weather Data Node",
  "type": "application/mcp-server-card+json",
  "url": "https://api.acme.com/mcp/weather.json",
  "capabilities": ["WeatherTool", "ForecastTool"],
  "description": "Enterprise weather MCP server for live telemetry.",
  "representativeQueries": [
    "what is the current wind speed in Chicago",
    "get the 5-day forecast for Seattle"
  ]
}

representativeQueries is the field most people skip and the one that does the most work. A discovery service matching a user’s phrasing against your entries has nothing else to match on. Write the questions a person would actually ask, not a keyword list.

Step 3: Wrap the entries in a manifest

The manifest schema is deliberately thin. Its description in the repository reads: “The document published at /.well-known/ard.json… ARD requires only an entries array of ARD entries.” entries is the only required member, and additional top-level members are permitted and ignored.

Here is a complete worked example for a documentation and content site: a hypothetical docs.example.com that publishes an MCP server for searching its own docs, a public API, and a Markdown documentation index.

{
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:docs-search",
      "displayName": "Example Docs Search",
      "type": "application/mcp-server-card+json",
      "url": "https://docs.example.com/mcp/server-card",
      "description": "Full-text and semantic search across Example's product documentation, changelog and API reference.",
      "capabilities": ["SearchDocs", "GetPage", "ListSections"],
      "tags": ["documentation", "search", "mcp-server"],
      "representativeQueries": [
        "how do I rotate an Example API key",
        "what changed in the Example API in August 2026",
        "which Example plan includes audit logs"
      ],
      "version": "1.2.0",
      "updatedAt": "2026-09-01T00:00:00Z"
    },
    {
      "identifier": "urn:air:example.com:api:public",
      "displayName": "Example Public API",
      "type": "application/vnd.oai.openapi+json;version=3.1.0",
      "url": "https://api.example.com/openapi.json",
      "description": "REST API for projects, members and audit events. OAuth 2.1 with delegated scopes; write operations accept an idempotency key.",
      "tags": ["api", "openapi", "rest"],
      "representativeQueries": [
        "create a project in Example",
        "list the audit events for an Example workspace"
      ],
      "updatedAt": "2026-08-14T00:00:00Z"
    },
    {
      "identifier": "urn:air:example.com:docs:index",
      "displayName": "Example Documentation Index",
      "type": "text/markdown",
      "url": "https://docs.example.com/llms.txt",
      "description": "Curated Markdown index of Example's documentation, for agents that want to read rather than call.",
      "tags": ["documentation", "index"],
      "representativeQueries": [
        "where is the Example getting started guide",
        "show me Example's documentation table of contents"
      ],
      "updatedAt": "2026-09-01T00:00:00Z"
    }
  ]
}

That third entry is the pattern most content sites will care about: ARD does not require you to have an agent. It lets you point at whatever machine-readable representation you already have, including your documentation index. This site publishes its own manifest at agentexperience.tech/.well-known/ard.json, using both patterns: a first entry for the read-only MCP server it runs at /api/mcp, which is the invocable resource ARD was written for, and further entries pointing at the documentation index, the guides and the rubric.

Step 4: Serve it correctly

Serve the file at https://your-domain/.well-known/ard.json with Content-Type: application/json, a 200, and permissive CORS if you want browser-based agents to read it. Serve it from the apex domain an agent would guess, not only from a subdomain.

Step 5: Add a secondary discovery route

The spec lists several mechanisms besides the well-known path (§5.1): in-page JSON-LD markup, an Agentmap: directive in robots.txt, a <link rel="ard" href="…"> element, and DNS Service Binding records under _entries._agents.example.com and _search._agents.example.com. The link relation is the cheapest:

<link rel="ard" href="https://example.com/.well-known/ard.json">

Consumers must honour rel="ard", per the same normative paragraph quoted earlier, so this is a real second route rather than decoration.

Step 6: Validate, then keep it honest

The specification repository ships a zero-dependency conformance CLI at conformance/bin/conformance-test, with modes for manifest validation, publisher resolution and registry validation. Run it in CI.

Then set a reminder to re-check the URLs in your entries every release. A manifest usually goes wrong by drifting rather than by becoming invalid: a url that 404s, a version that is two releases behind, an updatedAt from June.

Optional: the AI Catalog and a Server Card for an MCP server

If one of your entries is a remote MCP server and you want MCP clients that implement SEP-2127 to find it, add two more files, generated from the same list as ard.json:

1. A Server Card at <your-mcp-url>/server-card, served as application/mcp-server-card+json with Access-Control-Allow-Origin: *, built to the schema in the ext-server-card repository.
2. An AI Catalog at /.well-known/ai-catalog.json, with "specVersion": "1.0" and one entry per resource. The ARD entries can be reused as they are: AI Catalog consumers must ignore members they do not recognise, although the draft prefers custom data inside its extensions map.

Point the MCP entry in both files at the card rather than at the endpoint, and put the date you last checked both specifications in your release checklist. Both formats are drafts, and the card schema is the part most likely to change.

Optional: the registry side

If you want to consume ARD rather than publish it, the spec defines a registry API: POST /search is required, POST /explore and GET /agents are optional, with an OpenAPI 3.1.0 description and a CDDL schema in the repository, and federation modes auto, referrals and none. Anyone tempted to build a ranking on top of it should read one line in that section: the relevance score “reflects semantic relevance only and MUST NOT be interpreted as a trust, compliance, or safety judgment.”

What is the real adoption picture?

It is thin.

The only systematic public probe we have found is an independent audit repository, api-evangelist/agentic-resource-discovery, whose adoption file dated 31 July 2026 records probing 43,838 domains, of which 37,751 were reachable, and finding 12 manifest responses across 9 distinct publishers, with zero fully conformant. That was six weeks after launch, against the older ai-catalog.json path. It is one measurement by one party, so treat it as an indication rather than a census, but it is the only number in public, and it is small.

We found no comparable public count for AI Catalogs or Server Cards since SEP-2127 was merged, which is unsurprising two days after the merge. Early publisher examples and reference links can drift quickly, so treat the API Evangelist audit as a dated adoption snapshot rather than as durable implementation guidance. Before citing a live publisher, fetch its current manifest and validate it against the current spec.

What this means for you. Publishing an ARD manifest today is a low-cost, low-risk bet on a specification with credible backing and almost no installed base of readers. It is a reasonable bet, because the file takes an hour and it inventories invocable resources, which few other files do. It is not a reasonable basis for expecting traffic, discovery, or agent usage in the near term, and we would treat any claim that it produces those outcomes as unsupported.

What should a site publish today?

A short decision guide, with no promises attached.

• You run a remote MCP server. Publish ard.json with an entry for it. If you want MCP clients that implement Server Cards to find it, add a Server Card and an ai-catalog.json as described in the optional step above, generated from the same list. If you would rather wait for the formats to settle, an ARD entry pointing at the server is a reasonable place to stop for now.
• You run an A2A agent or a public API. Publish ard.json. This is the case the spec was written for, and the manifest is the cheapest way to make the resource findable from your own domain rather than from someone’s catalogue.
• You run a documentation or content site with no invocable surface. Publish a sitemap, dates, and an accurate Markdown index first. Do not add either manifest merely to claim a path: their scope is resources an agent can use, not a documentation index.
• You already publish ai-catalog.json. Keep it. It is now MCP’s discovery path as well as ARD’s old one. Add ard.json, and make the two agree.
• You are writing about ARD. Check the version header before you cite anything, and say which specification a path belongs to. ARD changed its manifest path and decoupled its schema within ten weeks of launch, and the old path then gained a new owner.

What this site does, and why

This site publishes /.well-known/ard.json, generated at build time from the same content collection as its pages, with its read-only MCP server listed as the first entry. It does not yet serve /.well-known/ai-catalog.json or a Server Card for /api/mcp.

The reason is status, not doubt about the direction. As of 8 October 2026 the AI Catalog specification describes itself as a draft that may change at any time and has no tagged release; the repository that holds the Server Card schema still calls itself experimental; and the SDK reference implementations are unmerged. ARD’s own text says a publisher does not need to serve the predecessor path. We will add both files when the AI Catalog publishes a version that is no longer a draft or the Server Card extension leaves experimental status, whichever comes first, and record the change here.

What is still unresolved?

• Whether the two specifications converge. ADR-0017 says they “evolve independently”. Their entries overlap today, but nothing guarantees they will stay compatible.
• Which file consumers read. ARD consumers must read ard.json. MCP clients that implement Server Cards should read ai-catalog.json. We found no public evidence yet of how many clients do either.
• Trust. Both formats carry an optional trust envelope. The AI Catalog defined signed entry Trust Manifests with a did:web profile on 1 October 2026; ARD leaves the framework open. How a consumer should weigh them is not settled.
• What a Server Card will include. Cards leave out tools, resources and prompts on purpose. SEP-2127 says a follow-on proposal should work out how to list them, and that a future revision can add capability fields.
• Registration. ARD describes the Server Card and A2A card media types as “tracking towards formal registration”. Until they are registered, expect small changes in names and fields.

Frequently asked questions

What is Agentic Resource Discovery? ARD is an open specification for publishing a machine-readable list of the agents, tools, servers and other resources a domain offers, at a well-known URL on that domain. Each entry says what a resource is and where to fetch its real description, rather than describing how to call it.

Is the file called ai-catalog.json or ard.json? Both files exist, and they belong to different specifications. ARD v0.91, dated 26 August 2026, uses /.well-known/ard.json and calls ai-catalog.json its predecessor path. The AI Catalog, a separate draft specification, uses /.well-known/ai-catalog.json, and MCP’s Server Cards proposal (SEP-2127, merged as Final on 6 October 2026) points domain-level discovery at it. ARD readers must fetch ard.json; MCP clients that implement Server Cards look for ai-catalog.json.

What is the difference between ard.json and ai-catalog.json? ard.json is an ARD manifest: it requires only an entries array, and each entry carries the signals a search service needs, chiefly representativeQueries. ai-catalog.json is an AI Catalog: it requires a specVersion and an entries array, each entry is a thin pointer (identifier, media type, and a URL or inline data), and it has an optional signed trust layer. The ARD specification says every ARD entry is a well-formed catalog entry, so one list can generate both.

Should I publish both ard.json and ai-catalog.json? Publish ard.json if you offer anything invocable. Add ai-catalog.json, with a Server Card for your MCP server, if you want MCP clients that implement SEP-2127 to find the server and you can re-check a draft format. Generate both from the same list so they cannot disagree. If you already publish ai-catalog.json, keep it: it is now MCP’s discovery path as well as ARD’s old one.

Does ARD replace llms.txt, AGENTS.md or MCP? No. The spec describes ARD as an envelope that wraps execution standards such as MCP, A2A and OpenAPI. It does not discuss llms.txt or AGENTS.md at all, and those address different problems: a documentation index and repository instructions.

Is anyone actually reading ARD manifests yet? Adoption is very early. The one systematic public probe we found, dated 31 July 2026, reported manifests from 9 distinct publishers across 37,751 reachable domains, none fully conformant. Publish it because it is cheap and correct, not because you expect traffic from it.

Who governs the specifications? ARD’s project publishes a governance page describing an oversight board and a maintainer group, and the repository names three code owners; the project’s own governance page frames a decision about a neutral host as roughly a year away. The AI Catalog is a temporary working repository maintained by the Linux Foundation, with a four-seat steering committee nominated by the MCP and A2A projects. Neither is a W3C or IETF standard as of 8 October 2026. ARD is licensed Apache-2.0.

ARD is worth publishing because it is cheap and honest about what it is. Do not over-claim it, because almost nobody is reading it yet.