# Agentic Resource Discovery: publish one file that tells agents what you offer. > Agentic Resource Discovery explained: what ARD is, how /.well-known/ard.json relates to MCP's ai-catalog.json, and a worked example you can copy to publish your own. Published: 2026-09-07 Updated: 2026-10-08 Changelog: 2026-10-08: Rewrote the relationship between ard.json and ai-catalog.json after MCP's Server Cards proposal (SEP-2127) was merged as Final on 6 October 2026: ai-catalog.json is now described as the path of the separate AI Catalog draft that MCP uses for domain-level discovery, not only as ARD's old path. Added what each file is, who defines it, its status, what to publish today, what remains unresolved, and why this site does not yet serve ai-catalog.json. Updated the FAQ. Changelog: 2026-09-19: Rewrote the title tag, meta description and H1 to lead with Agentic Resource Discovery and the ard.json publishing task. Canonical: https://agentexperience.tech/insights/agentic-resource-discovery/ Tags: discovery, standards, ard, well-known, mcp **Summary** Publish `/.well-known/ard.json` if you offer an MCP server, an agent or an API. `ard.json` belongs to the Agentic Resource Discovery proposal; `/.well-known/ai-catalog.json` now belongs to a separate draft, the AI Catalog, which MCP's Server Cards use for domain-level discovery. Both are cheap, neither is final, and you can generate both from one list. 1. Agentic Resource Discovery (ARD) lets a domain publish one manifest listing the agents, tools and servers it offers, with each entry pointing at the resource's real description. 2. As of ARD v0.91, dated 26 August 2026, ARD's path is /.well-known/ard.json, and ARD calls /.well-known/ai-catalog.json its predecessor path. 3. ai-catalog.json did not go away: it is the path of the AI Catalog, a separate draft specification, and MCP's Server Cards proposal (SEP-2127, merged as Final on 6 October 2026) points domain-level discovery at it. 4. Every ARD entry is also a valid AI Catalog entry, so one list of resources can generate both files without them disagreeing. 5. Both formats are early: ARD is a proposal, the AI Catalog says it is a draft that may change at any time, and the one public ARD probe found manifests from 9 publishers across 37,751 reachable domains. 6. Publish ard.json if you run an MCP server, an agent or a public API; add ai-catalog.json and a Server Card if you want MCP clients to find your server and can re-check a draft format; do not expect discovery traffic yet. Agentic Resource Discovery is an envelope, not an execution protocol. It tells an agent that a resource exists and where to fetch its real description. **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](#how-do-ardjson-and-ai-catalogjson-relate) 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](#what-is-the-real-adoption-picture) 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`](https://github.com/ards-project/ard-spec). Rechecked 8 October 2026 against ARD v0.91, [SEP-2127](https://modelcontextprotocol.io/seps/2127-mcp-server-cards) and the [AI Catalog draft](https://ai-catalog.io/spec/).* ## 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](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/) - Announcement: [Microsoft, "Introducing the Agentic Resource Discovery specification", 17 June 2026](https://commandline.microsoft.com/agentic-resource-discovery-specification-ard/) - Announcement: [Hugging Face, "Agentic Resource Discovery: Let agents search for tools, skills, and other agents", 17 June 2026](https://huggingface.co/blog/agentic-resource-discovery-launch) - Later coverage: [AWS, "Agentic Resource Discovery (ARD): An open specification for agent discovery", 24 August 2026](https://aws.amazon.com/blogs/machine-learning/agentic-resource-discovery-ard-an-open-specification-for-agent-discovery/); [InfoQ, 14 July 2026](https://www.infoq.com/news/2026/07/agentic-resource-discovery-spec/) - Canonical spec: [agenticresourcediscovery.org/spec/](https://agenticresourcediscovery.org/spec/), rendered from [`ards-project/ard-spec`](https://github.com/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`](https://github.com/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"](https://github.com/Agent-Card/ai-catalog/blob/main/adr/0017-ard-loose-coupling.md), 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. | | `ard.json` | `ai-catalog.json` | |---|---|---| | Defined by | Agentic Resource Discovery ([agenticresourcediscovery.org](https://agenticresourcediscovery.org/spec/)) | AI Catalog ([ai-catalog.io](https://ai-catalog.io/spec/)) | | Status, 8 October 2026 | v0.91, "Proposal", 26 August 2026 | Draft that "may be updated at any time"; no tagged release | | Required at the top level | `entries` | `specVersion` and `entries` | | Required in each entry | `identifier`, `displayName`, `type`, and one of `url` or `data` | `identifier`, `type`, and one of `url` or `data` | | Link relation | `rel="ard"` | `rel="ai-catalog"` | | Is the well-known path required? | ARD consumers MUST fetch it | Optional for publishers; clients doing domain-level discovery SHOULD try it | | Emphasis | Search signals, chiefly `representativeQueries` | Thin pointers, plus optional signed Trust Manifests | | Who points at it | ARD discovery services | MCP Server Cards (SEP-2127) | 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. ![One list of the resources you actually expose, highlighted, produces two files. On the left, ard.json, for the ARD proposal, which adds displayName and representative queries and is read by discovery services, since ARD readers must fetch it. On the right, ai-catalog.json, for the AI Catalog draft, which adds specVersion and is read by MCP clients that use Server Cards.](https://agentexperience.tech/diagrams/ard-and-ai-catalog.svg) *Figure: One list, two files: each specification adds its own fields and has its own readers.* ### 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"](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2127). It was opened on 21 January 2026 and merged on 6 October 2026, and the MCP site now lists it as [Final](https://modelcontextprotocol.io/seps/2127-mcp-server-cards). 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 `/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: ```json { "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`](https://github.com/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. ![How an agent uses an ARD manifest, in four steps from top to bottom. 1. Fetch the manifest at /.well-known/ard.json, or through an ard link relation. 2. Read each entry: identifier, displayName, type, a url or inline data, and representative queries. 3. Follow the entry's url to an MCP Server Card, an A2A agent card, an OpenAPI document or a Markdown index. A dashed line after step 3 marks where ARD ends. 4. Call the resource through MCP, A2A or the API itself.](https://agentexperience.tech/diagrams/ard-envelope.svg) *Figure: ARD tells an agent what exists and where to read about it; the call itself goes through the resource's own protocol.* 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. | | ARD (`ard.json`) | AI Catalog (`ai-catalog.json`) | `llms.txt` | `AGENTS.md` | MCP Server Card | |---|---|---|---|---|---| | Object | Invocable resources on a domain | AI artefacts on a domain | Documentation pages | Repository conventions | One remote MCP server | | Location | `/.well-known/ard.json` | `/.well-known/ai-catalog.json`, or any URL | Site root | Repository, nearest file wins | Any URL; `/server-card` recommended | | Read by | ARD discovery services | MCP clients that implement SEP-2127 | Retrieval agents, unevenly | Coding-agent harnesses | MCP clients, before connecting | | Says | "This exists, fetch it here" | "These artefacts exist, fetch them here" | "Read these docs" | "Build and test like this" | "Connect to this server like this" | ## 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: | Term | Requirement | Notes | |---|---|---| | `identifier` | MUST | URN of the form `urn:air:::`. Schema pattern: `^urn:air:[a-zA-Z0-9.-]+(:[a-zA-Z0-9._-]+)+$` | | `displayName` | MUST | Human-readable name | | `type` | MUST | An IANA media type describing the *target* document | | `url` **or** `data` | MUST (exactly one) | Point at the description, or inline it | | `representativeQueries` | SHOULD | The spec says it "SHOULD contain 2–5 examples"; failing this is a conformance **warning**, not an error | | `capabilities` | MAY | Named capabilities | | `description`, `tags`, `version`, `updatedAt`, `metadata`, `trustManifest` | Optional | `@context` and `@id` are also available for JSON-LD | The specification's own example entry, verbatim from §4.4: ```json { "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. ```json { "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](/.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 `` element, and DNS Service Binding records under `_entries._agents.example.com` and `_search._agents.example.com`. The link relation is the cheapest: ```html ``` 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 `/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`](https://github.com/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`](/.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.