Right now an agent only knows about the tools someone set up for it. You paste an MCP server into a config file, and that’s its whole world. That works when there are five tools. It doesn’t work when there are fifty thousand.

Agentic Resource Discovery is a proposal for fixing that. Version 0.91 came out on August 26, written by Junjie Bu at Google, R.V. Guha at Microsoft and Shaun Smith at Hugging Face, with contributors from GitHub, GoDaddy, Snowflake and others. Guha also worked on RSS and Schema.org, which is about the right résumé for this.

The idea is to take tool discovery out of the model’s context window and put it in a search service.

A publisher puts a manifest at /.well-known/ard.json. A registry indexes it. An agent sends a plain-English question to the registry and gets back the entries that match, then connects to the one it needs. Nothing gets stuffed into the context up front.

0xinsider has had a manifest for a while, and this week I rebuilt it to match v0.91. Here’s the main entry:

1
{
2
  "identifier": "urn:air:0xinsider.com:mcp:prediction-market-intelligence",
3
  "displayName": "0xinsider MCP server",
4
  "type": "application/mcp-server-card+json",
5
  "url": "https://0xinsider.com/.well-known/mcp",
6
  "representativeQueries": [
7
    "which Polymarket wallets placed the largest trades on tonight's NBA game",
8
    "grade this Polymarket wallet by settled P&L",
9
    "where is sharp money concentrated on this Premier League market",
10
    "show the Polymarket leaderboard for esports traders",
11
    "what sports games are on today and which Polymarket markets cover them"
12
  ]
13
}

Four fields are required: identifier, displayName, type, and exactly one of url or data. The identifier is a URN anchored to your domain, urn:air:<publisher>:<namespace>:<name>. The type is a media type, so the same envelope can describe an MCP server, an A2A agent or a skill without ARD having to know anything about them.

representativeQueries is the field I spent the most time on. It holds 2 to 5 things a person might actually ask, and it’s what a registry builds its semantic index from. Writing them felt a lot like writing search keywords, except the reader is a model instead of Google.

0xinsider publishes nine entries: the product MCP server, the documentation MCP server, and seven agent skills covering things like wallet grades and large trades. The manifest carries a trustManifest that binds everything to https://0xinsider.com. The spec requires the publisher in every URN to match that identity, so a registry can check that an entry claiming to be 0xinsider really comes from 0xinsider.com.

The official conformance tool is a single Python file with no dependencies:

1
git clone https://github.com/ards-project/ard-spec && cd ard-spec
2
python3 conformance/bin/conformance-test manifest https://0xinsider.com/.well-known/ard.json

It checks every entry’s URN, the value-or-reference rule and the trust binding, then prints one verdict:

1
CONFORMANCE STATUS: PASS
2
Validated with 0 critical specification errors and 0 warnings.

The first thing I got wrong had nothing to do with JSON. Our firewall challenges traffic that doesn’t look like a browser, and verified crawlers like GPTBot get waved through. Registries aren’t verified crawlers. So /.well-known/ard.json answered 429 to exactly the clients it exists for, while the older ai-catalog.json path right next to it answered 200. The fix was one line in a bypass rule. If you publish a manifest, fetch it from a server with curl, not from your own browser.

Then I asked a registry about it. ora.ai runs one with the POST /search endpoint from the spec:

1
curl -s -X POST https://ora.ai/api/ard/search \
2
  -H 'Content-Type: application/json' \
3
  -d '{"query":{"text":"Polymarket MCP server"},"pageSize":5}'

On September 23 it didn’t return 0xinsider. Searching for “0xinsider” by name does find us, but as entries ora wrote itself, like urn:air:ora.ai:product:0xinsider.com, not the nine I published. The registry knows the site exists. It hasn’t ingested the manifest yet.

That’s where ARD is today. The publishing side is ready: a manifest is a static JSON file, and the conformance tool tells you in a second if it’s wrong. The search side, where registries crawl manifests and answer questions with them, is early. The spec still says “Proposal” at the top.

I’m doing it anyway because 0xinsider is built for agents as much as for people. The data behind it is also a read-only REST API and an MCP server. When someone asks an agent which Polymarket wallets are behind tonight’s NBA game, I want it to find 0xinsider without anyone pasting a URL into a config file first. ARD is the first proposal I’ve seen that gets there without one company owning the directory.

If you want to add one to your own site:

• Write /.well-known/ard.json with one entry per thing an agent can use, and give each entry 2 to 5 real questions.
• Run the conformance tool against the live URL.
• Fetch it with curl from a server to make sure your firewall lets registries in.

It’s a small JSON file. The hard part is writing questions someone would actually ask.