What is ARD?
ARD is short for Agentic Resource Discovery, an open specification for how
AI agents find the tools, skills, agents and APIs they need, published in June 2026
by a working group including Google, Microsoft, Hugging Face, AWS, Cisco, GitHub,
Nvidia, Salesforce and Snowflake.
An agentic resource is anything an AI client can call to get work done: an MCP
server, an A2A agent, a skill, an API, a workflow.
ARD answers one question, "what is available for this task?", and then gets out
of the way. It is not a runtime and does not replace MCP or A2A. It tells an agent
what exists; the agent connects using the resource's own protocol.
Since 30 October 2026 ARD is also three IETF Internet-Drafts in the DAWN effort
(Discovery of Agents With Names), under the name Agent Resource Discovery. Same
protocol, same /.well-known/ard.json, same urn:air identifiers. This registry follows
both the specification (v0.91) and the drafts; see IETF drafts below.
The problem it solves
Today an agent can only use capabilities someone installed for it in advance. Every
tool has to be wired in by hand, and every tool description has to sit in the context
window, competing for space with the actual work. That model does not survive contact
with an ecosystem of thousands of tools, let alone millions.
ARD moves the selection problem out of the context window and into a search service, the same shift the early web made when it went from curated link directories to
search engines.
For that to work, two sides have to exist. Publishers describe what they offer at
a well-known location on their own domain. Registries index those descriptions and
answer queries. Neuronto is both.
Why a federated index
The specification defines three federation modes and makes auto the default: a
registry queries its peers, merges their results, and returns one set.
In practice each public registry answers only from its own catalogue, so the same
question asked in four places returns four different answers and the client has to
pick a side. That is the problem Neuronto exists to remove.
Ask Neuronto once and the query fans out across every public ARD registry
concurrently. Results are fused with reciprocal rank fusion, which combines the
orderings rather than the scores, necessary because each registry calibrates
differently, and importing another service's scoring would import its biases with it.
The response says which registries answered and which timed out, so a caller always
knows how much of the federation is behind an answer.
What it does differently
Federated by default. federation: auto implemented as specified: concurrent
fan-out under a hard time budget, fused ranking, per-upstream reporting. A slow peer
costs the budget and nothing more.
Complete conformance. Passes the specification's official conformance tool as
both a registry and a publisher with zero errors and zero warnings, including the
optional GET /agents listing as a properly paginated object.
Type normalisation. Three media types for MCP servers are in circulation
(application/mcp-server, application/mcp-server+json,
application/mcp-server-card+json) and two URN prefixes appear as discovery
identifiers (urn:air: and urn:ai:). Because filters match exactly, entries get
dropped silently. Neuronto normalises both on ingest, so a filter for MCP servers
returns them however the publisher spelled the type.
A verified tool index, not just a server index. Every other registry stores a server
name and whatever prose its publisher wrote. Neuronto handshakes with each indexed MCP
endpoint and reads its tools/list, so the index holds the real tool names and input
schemas, the thing an agent actually has to match on. Currently 32,183 verified tools
across 2,223 servers, plus 1,918 endpoints recorded as requiring credentials, which
no other registry reports. Introspection is read only: a tool is never called.
Hybrid retrieval. Sparse BM25 and dense vectors, fused with the same reciprocal rank
fusion used for federation, so one query runs lexical, semantic and federated retrieval and
returns a single ordering. The dense leg rides inside the federation budget and contributes
nothing if it is unavailable, so the lexical fast path is never slowed by it.
Verified liveness. Indexed endpoints are probed and non-responding ones demoted
in ranking. Registries built on self-published manifests accumulate dead links
quickly; serving them is the fastest way to become the index nobody trusts. Entries
are demoted rather than deleted, because services come back.
Manifests generated from evidence, not from a form. Most domains will never author a
manifest by hand. They already run an MCP server, or serve an OpenAPI document, or publish
llms.txt, and the manifest is a restatement of things a crawler can already find. Neuronto
probes a domain, emits an entry only for each resource that actually answered, records what
proved it, and hosts the result. Nothing is inferred, because a generated manifest that
guesses would put a claim on somebody's domain that they never made and cannot defend.
A private half of the index. The list of internal services an organisation's own agents
may call usually lives in a system prompt, where nothing can search it and nobody can audit
it. A domain that proves ownership by DNS can register those services, and one query then
returns internal and public results together, each labelled with which it is. Private
entries are held in separate storage from the public index rather than behind a flag, so no
public search, count or page can reach them by construction.
Payment terms, before the call. A paid endpoint used to be found, called, and only
then answer 402 Payment Required. Neuronto reads what a resource costs from two places
and keeps them apart: what its manifest declares (the pay: terms of the specification's
worked example, schema:offers, and catalogue formats that carry a price), and what the
endpoint itself answers when it is called without payment (x402 terms in a
PAYMENT-REQUIRED header or a 402 body, or an MPP challenge). A server that asks to be
paid is recorded as reachable, not as broken. Results carry pay:protocol, pay:price,
pay:currency and pay:network, with paymentEvidence saying whether a live 402
confirmed them, and a search can be filtered on them:
Paying for heavy calls. A self-hosted Neuronto charges nothing. On neuronto.com, the
calls that do outbound work for the caller, a federated search, an audit or a manifest
build, are free up to an allowance. Past it, the 429 carries an x402 price in a
PAYMENT-REQUIRED header, and an agent that pays gets the call instead of a wait; a client
that sends x-payment-protocol: x402 gets the 402 directly. Only a call that succeeded is
settled. Submitting a resource, claiming a domain, being listed and position in results are
never charged. GET https://neuronto.com/x402 states the live terms.
Terms never change a score, and the registry never handles a payment: the caller pays the
provider directly.
Settling the payments, if you want that from us as well. Reading a price is one half of
the problem; taking the money is the other. Neuronto also operates a hosted x402 facilitator at
pay.neuronto.com, which any x402 server can point at in one line: it
checks a buyer's signed stablecoin payment and settles it on-chain, and it never holds anyone's
funds, because the buyer signs the transfer and the facilitator only broadcasts it. Live on Base,
free while it is new. A live endpoint there charges a tenth of a cent and sends it straight back in
the same request, so a client can be run end to end for nothing, and
pay.neuronto.com/status publishes what it has been observed to
do rather than a promise about it.
It is a separate hosted service: it is not part of this repository, nothing here depends on it, a
self-hosted Neuronto never contacts it, and no resource is ever ranked differently for using it or
for not using it.
Ranking that separates. A relevance score is only useful if the gap between the
first and fifth result is legible. Scores are scaled to preserve real separation
instead of compressing everything into a narrow band.
Where it fits
- Agent builders, stop hard-coding integrations. Ask for a capability at runtime
and connect to whatever currently serves it best.
- API and tool vendors, publish one manifest on your own domain and become
discoverable to every ARD client, without applying to a curated marketplace.
- Platform teams, run discovery over internal services so agents inside the
organisation find them the same way they find public ones.
Using it
Search this index and the whole federation in one call:
Or install it as an MCP server, so an agent searches from the interface it already
speaks:
Registry API
Every GET route also answers HEAD with the same headers and no body. The root answers
with Link: <https://neuronto.com/.well-known/ard.json>; rel="ard", and errors from
/search, /explore and /agents are RFC 9457 Problem Details
(application/problem+json) carrying the draft's codes, for example INVALID_ARGUMENT.
Knowing when the answer is weak
Every top result scores near 100. That is deliberate: the score is relative to the best hit
in its own result set, because BM25 magnitudes are corpus and query dependent, so an
absolute scale would mean nothing. It ranks well and, on its own, it misleads. The query
zzzz nonexistent capability qqqq scores 100, because something always comes first.
So every search response carries one absolute number beside the relative ones:
coverage is the fraction of the query's content words that the top result's own text
accounts for. It is corpus independent, which is the property the score cannot have, so it
separates "the best of several good answers" from "the best of nothing".
It measures overlap, not correctness. A query whose every word appears in an entry that
does the opposite thing still scores 1.0. Treat it as a floor on confidence, never as a
verdict, and never as a trust or safety rating.
No key and no signup for anything that reads the public index. A key exists only to admit a
verified domain's own private entries, and is issued only against a DNS proof of ownership.
Relevance scores are semantic only and are never a trust, compliance or safety rating, the
specification is explicit that trust evaluation is decoupled from discovery.
Searching tools instead of servers
When you already know the shape of the call you need, the server hosting it is an
implementation detail:
Every tool returned was read from that server's own tools/list. The same search is
available to agents as the MCP tool find_tool, alongside find_resource,
registry_stats and publish_resource. Only publish_resource writes, and it is the only
one declaring readOnlyHint: false, so a client can tell from the tool list alone which
call has an effect.
Measuring whether any of this works
GET /bench publishes ARD-Bench, a head to head retrieval measurement across the public
ARD registries, and GET /bench.json serves the same run as plain JSON with its age.
The harness is app/bench.py and it is refreshed weekly.
The task set is a file, and it is frozen. bench/declared-v1.json
(also served at /bench/tasks.json) holds 192 tasks, one per publisher. Each query was read
verbatim from the manifest on the publisher's own domain, and the task records that
manifest's URL and the sha256 of the body it came from, so anyone can check that a query
is the publisher's words and not ours. The file carries a digest over its tasks and is never
edited in place; a new set is a new version. It is split by publisher into a tune half,
the only half any ranking parameter may be chosen on, and a holdout half, which is what
the benchmark reports.
The response separates two things that are easy to confuse: coverage, whether a registry
indexes the target at all, and recall@k_when_carried, whether it retrieves the target
when it does hold it. Our own coverage is 1.0 by construction, because the tasks come from
resources in this index, and the payload says so.
Ranking weights are measured, not asserted, and each one in app/rank.py sits next to
the table it was chosen from. scripts/evalgate.py runs daily against a pinned baseline
(bench/baseline.json): holdout recall@10 and MRR, a battery of
ordinary capability requests (scripts/battery.py) that may not lose a case, and the rule
that federated search never scores below local search. A drop fails the gate.
Federation adds coverage, it does not re-rank. In federation: auto the other
registries are asked only when this index cannot answer with confidence, and what they
return may add resources this index lacks without reordering the ones it found. On the
holdout, auto and none both reach recall@10 0.934, auto with the higher MRR, at a
median of 177 ms against 121 ms.
What happens to a query
Every search response carries queryHandling and a Neuronto-Query-Handling header: whether
the query text was kept, which registries it was sent to for this answer, and whether it was
embedded. "federation": "none" never leaves the service. A search with an API key, or
carrying Sec-GPC: 1 or DNT: 1, is counted but its text is not kept, and search records
are deleted after 90 days. The full statement is at /privacy.
IETF drafts
On 30 October 2026 ARD was submitted to the IETF as three Internet-Drafts. They are
individual drafts, version 00, valid until 3 May 2027; not an RFC.
What this registry does for each requirement that differs from v0.91 of the specification:
The specification's conformance tool still reports PASS with 0 errors and 0 warnings for
both the manifest and the registry.
On 2 November 2026 we checked the 460 domains our crawler knows publish a manifest. 179
serve one at /.well-known/ard.json, none of them as application/ard+json (170 as
application/json); 34 send Link: rel="ard" on the root; 50 publish an SVCB record at
_index._agents, of which 14 lead to a manifest; none publish a DNS-SD record.
Who publishes an ARD manifest
GET /adoption tracks adoption of the specification itself: a named watchlist of
organisations, and the manifest rate across every host the crawler has seen. At the time
of writing, three of the twenty organisations on the watchlist publish a manifest:
Hugging Face, Vercel and Zapier. All three serve it at /.well-known/ai-catalog.json,
the path v0.91 renamed. Of 178 publishers our crawler has found, 157 serve the older
ai-catalog.json and only 14 serve ard.json, which is why the tracker checks both:
measuring the path rather than the practice gets the answer wrong.
The open dataset
The verified tool corpus is published as an open dataset, CC BY 4.0:
huggingface.co/datasets/AgenticResourceDiscovery/verified-mcp-tools
tools.jsonl carries all 31,411 verified tools with their input schemas, servers.jsonl
carries 7,708 introspection results including the auth requirement and failure kind. It
exists because tool-retrieval research (ToolRet, ACL Findings 2025) has been benchmarked on
assembled corpora rather than the live ecosystem, and this is the live ecosystem.
The badge
If your MCP server is in the index, a badge states what we verified: how many tools your
server returned to tools/list, and whether the endpoint answers.
The publisher id is the publisher segment of your URN, or your domain. The badge is a
statement about what was observed, never a trust, safety or quality rating. Not indexed
yet? Publish a manifest and the crawler will find you, or run the
console audit.
Publishing your own resources
Four ways in, in ascending order of effort. There is no allowlist and no signup for any
of them.
You already run an MCP server. Submit the endpoint. Neuronto completes an initialize
handshake and reads the server's own tools/list, which is stronger evidence than a
manifest claim because the server answered for itself.
You are working inside an agent. The same thing as an MCP tool, so a resource can be
listed from inside a conversation without leaving it.
It verifies rather than trusts, exactly as the HTTP route does, and calls that route rather
than reimplementing it so the two cannot drift apart.
A submission is never lost. If the endpoint does not verify at that moment, for any
reason, the answer is 202 with "status": "pending", a submission id, and evidence:
the HTTP status, content type and first bytes of what the endpoint actually returned, or
the JSON-RPC error it sent. The registry keeps the submission and retries it on a fixed
schedule (1 min, 5 min, 15 min, 1 h, 4 h, 12 h, 24 h, 24 h) until it verifies or the
attempts run out, and GET /submit/status/{id} shows where it stands. A refusal caused by
the registry itself, such as the index being busy, costs none of those attempts. So a
server that was mid-deploy, a DNS record that had not propagated, or a client that gave up
after one call still ends up indexed with no second submission from anyone. The queue is
counted publicly at /metrics.json under submissions.
The other write endpoints answer honestly when the index is busy. POST /claim/verify,
POST /private/add and POST /private/delete return 503 with a Retry-After header and
"status": "busy" instead of failing in an unnamed way; the DNS proof or the request is
not lost, call again after the stated seconds. POST /manifest/build still returns the
generated manifest and reports "hosted_at": null with a note when only the hosted copy
could not be stored.
You have no manifest and do not want to write one. Ask for one to be generated from
what your domain already exposes, and either copy it or link it.
Only resources that actually answered become entries, and each carries the evidence that
produced it. The hosted copy at https://neuronto.com/m/example.com.json says in its own
response headers that it was generated rather than authored by the domain owner.
You have a manifest. Serve it at /.well-known/ard.json and submit the domain, or wait
for the crawler.
Serve it at /.well-known/ai-catalog.json as well. Version 0.91 of the specification
renamed the file, but the deployed base has not moved: of the ARD publishers verified so
far, the large majority still serve only the older path, so a consumer that checks one name
misses most of the ecosystem.
Include representativeQueries on every entry. It is the term registries build their
semantic index from, and an entry without it is a valid catalogue entry that no
search will ever return.
Checking whether it worked
Reports whether the manifest is reachable on each of the four discovery paths, whether it
satisfies the specification entry by entry, which registries actually return you, and
who is returned instead of you for the queries you asked to be found for, with what
those entries have that you may not. Free, no signup. There is a browser version at
/console.
Last step, whichever way you came in: add the badge. Once a registry returns you, put
it on your README or site. It states what was observed, the verified tool count and whether
your endpoint answered, corrects itself when that changes, is free, and changes nothing
about your indexing or ranking. Every response above ends with the same sentence and the
paste-ready snippet; the badge page has the formats.
Private entries
An organisation can register the internal services its own agents may call, and search
across public and internal resources in one query.
The proof value is derived from the domain and never changes, so asking again does not
invalidate a record already published. It is read over DNS over HTTPS, so it verifies as
soon as the authoritative zone serves it. Verification is the only thing that issues a key.
Every result says whether it came from the public index or from your own entries. Private
entries are never ranked against public ones by corpus statistics, because a single tenant's
index is too small for those statistics to mean anything; they are placed by how much of the
query their own text accounts for, which means the same thing at any size.
Specification
Licence
Apache-2.0
