ARD reference

Agentic Resource Discovery, explained properly

The specification says agents should find capabilities the way a search engine finds pages. This is a working reference for how that actually goes: what the format requires, what the announcements got out of date, and what the ecosystem looks like when you measure it.

The problem ARD was written to solve

An agent is only as good as the tools it can reach, and the way it reaches them today does not survive contact with scale. You install an MCP server by pasting a URL into a config file. You add a skill by cloning a repository. Every capability your agent has is one somebody decided in advance to wire in.

That breaks in two directions at once. The first is obvious: an agent cannot use a tool nobody told it about, so it fails at tasks a tool exists for. The second is the one that bites in production. Tool descriptions go into the context window, so every tool you add costs tokens on every single request, and accuracy starts falling long before you run out of room. The specification puts the problem plainly:

Agent descriptions tend to be generic, and most LLMs currently select tools by including all descriptions in the context window, which does not scale. ARD addresses this by moving discovery outside the LLM into a dedicated search service, where richer signals (representative queries, publisher identity, compliance metadata, usage patterns) can be leveraged without consuming context window tokens.

ARD specification v0.91, section 2, Motivation agenticresourcediscovery.org

So the fix is not a better prompt or a bigger window. It is to stop carrying the catalogue around. Ask a search service at the moment you need something, get back the two or three capabilities that fit, and load only those.

How ARD works

Two pieces, and the whole design falls out of them.

A client with a job to do sends a plain-language description of the job to a registry. The registry returns matching entries with the metadata needed to verify who published them. The client verifies, connects to the resource over that resource's own protocol, and ARD is out of the picture. It never sits in the data path.

Found by what it does, not what it is called

This is the part most summaries skip, and it is the part that changes how you should write an entry. Ranking is built from representativeQueries: two to five plain sentences saying what someone would ask when they need this resource. Not keywords, not a category, actual questions.

The effect is easy to underrate until you watch it work. Searching our own index for scrape a page behind Cloudflare returns servers named cloro and Hydrafetch. Neither name contains a word from that query. They rank because someone wrote down what they are for. A well described tool with a bad name beats a badly described tool with a good one, which is not how any package registry has ever worked.

What counts as an agentic resource

Deliberately broad. The specification calls ARD an artifact-agnostic envelope: it identifies what a thing is with an IANA media type and leaves the internals to whichever protocol owns them. In practice these are the families that actually exist in the wild today, counted from 14,732 indexed entries:

Counted 4 September 2026 across 6,610 publishers. Live figures and method on State of ARD.

What it looks like

Here is a complete, valid manifest. This is not a cut down illustration, it is the whole file. If you host this at https://yourdomain.com/.well-known/ard.json you are published.

{
  "specVersion": "1.0",
  "host": {
    "displayName": "Acme Weather",
    "identifier": "did:web:acme.com",
    "documentationUrl": "https://acme.com/docs"
  },
  "entries": [
    {
      "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",
      "description": "Live weather telemetry and forecasts for any coordinate.",
      "capabilities": ["WeatherTool", "ForecastTool"],
      "representativeQueries": [
        "what is the current wind speed in Chicago",
        "get the 5-day forecast for Seattle",
        "is it going to rain in Berlin tomorrow"
      ]
    }
  ]
}

Four terms are required on an entry: identifier, displayName, type, and exactly one of url or data. Everything else earns its place. The full field reference explains each one, including the traps.

Where the ecosystem actually stands

ARD was announced on 17 June 2026. Most of what has been written about it dates from that week and describes intentions. These are measurements, taken 4 September 2026 from a public index that crawls manifests, MCP endpoints and the other public registries.

The interesting number is not any of those. It is this one: of 8,543 endpoints asked to list their tools, only 2,607 answered. 2,072 demanded credentials, which is fair. But 1,236 returned 404 and 558 returned 405, and a good share of those are servers that work perfectly well and are simply answering the wrong way to a discovery request. Their owners almost certainly do not know.

The full report breaks that down by cause, with the method written out and the raw counts served as JSON.

Start here

If you publish something an agent could call

The whole distance between having built a thing and having it found is one static file and one request. There is no application, no review and no waiting list.

curl -X POST https://neuronto.com/submit \
  -H "Content-Type: application/json" \
  -d '{"url": "https://yourdomain.com"}'

Common questions

Forty more questions and answers.

Last reviewed 2026-09-04. Checked against ARD v0.91 (Proposal, 2026-08-26).