Neuronto ARD Registry: Agentic Resource Discovery (ARD) Index

What is ARD?

ARD is short for Agentic Resource Discovery, an open specification for howAI agents find the tools, skills, agents and APIs they need, published in June 2026by 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 MCPserver, an A2A agent, a skill, an API, a workflow.

ARD answers one question, "what is available for this task?", and then gets outof the way. It is not a runtime and does not replace MCP or A2A. It tells an agentwhat exists; the agent connects using the resource's own protocol.

The problem it solves

Today an agent can only use capabilities someone installed for it in advance. Everytool has to be wired in by hand, and every tool description has to sit in the contextwindow, competing for space with the actual work. That model does not survive contactwith 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 tosearch engines.

For that to work, two sides have to exist. Publishers describe what they offer ata well-known location on their own domain. Registries index those descriptions andanswer queries. Neuronto is both.

Why a federated index

The specification defines three federation modes and makes auto the default: aregistry queries its peers, merges their results, and returns one set.

In practice each public registry answers only from its own catalogue, so the samequestion asked in four places returns four different answers and the client has topick a side. That is the problem Neuronto exists to remove.

Ask Neuronto once and the query fans out across every public ARD registryconcurrently. Results are fused with reciprocal rank fusion, which combines theorderings rather than the scores, necessary because each registry calibratesdifferently, 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 alwaysknows how much of the federation is behind an answer.

What it does differently

Federated by default. federation: auto implemented as specified: concurrentfan-out under a hard time budget, fused ranking, per-upstream reporting. A slow peercosts the budget and nothing more.

Complete conformance. Passes the specification's official conformance tool asboth a registry and a publisher with zero errors and zero warnings, including theoptional 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 discoveryidentifiers (urn:air: and urn:ai:). Because filters match exactly, entries getdropped silently. Neuronto normalises both on ingest, so a filter for MCP serversreturns them however the publisher spelled the type.

A verified tool index, not just a server index. Every other registry stores a servername and whatever prose its publisher wrote. Neuronto handshakes with each indexed MCPendpoint and reads its tools/list, so the index holds the real tool names and inputschemas, the thing an agent actually has to match on. Currently 32,183 verified toolsacross 2,223 servers, plus 1,918 endpoints recorded as requiring credentials, whichno other registry reports. Introspection is read only: a tool is never called.

Hybrid retrieval. Sparse BM25 and dense vectors, fused with the same reciprocal rankfusion used for federation, so one query runs lexical, semantic and federated retrieval andreturns a single ordering. The dense leg rides inside the federation budget and contributesnothing if it is unavailable, so the lexical fast path is never slowed by it.

Verified liveness. Indexed endpoints are probed and non-responding ones demotedin ranking. Registries built on self-published manifests accumulate dead linksquickly; serving them is the fastest way to become the index nobody trusts. Entriesare demoted rather than deleted, because services come back.

Manifests generated from evidence, not from a form. Most domains will never author amanifest by hand. They already run an MCP server, or serve an OpenAPI document, or publishllms.txt, and the manifest is a restatement of things a crawler can already find. Neurontoprobes a domain, emits an entry only for each resource that actually answered, records whatproved it, and hosts the result. Nothing is inferred, because a generated manifest thatguesses 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 agentsmay call usually lives in a system prompt, where nothing can search it and nobody can auditit. A domain that proves ownership by DNS can register those services, and one query thenreturns internal and public results together, each labelled with which it is. Privateentries are held in separate storage from the public index rather than behind a flag, so nopublic search, count or page can reach them by construction.

Ranking that separates. A relevance score is only useful if the gap between thefirst and fifth result is legible. Scores are scaled to preserve real separationinstead of compressing everything into a narrow band.

Where it fits

• Agent builders, stop hard-coding integrations. Ask for a capability at runtimeand connect to whatever currently serves it best.
• API and tool vendors, publish one manifest on your own domain and becomediscoverable to every ARD client, without applying to a curated marketplace.
• Platform teams, run discovery over internal services so agents inside theorganisation find them the same way they find public ones.

Using it

Search this index and the whole federation in one call:

curl -s https://neuronto.com/search \
  -H 'content-type: application/json' \
  -d '{"query":{"text":"scrape a website behind cloudflare"},"federation":"auto"}'

Or install it as an MCP server, so an agent searches from the interface it alreadyspeaks:

claude mcp add --transport http neuronto https://neuronto.com/mcp

Registry API

Knowing when the answer is weak

Every top result scores near 100. That is deliberate: the score is relative to the best hitin its own result set, because BM25 magnitudes are corpus and query dependent, so anabsolute scale would mean nothing. It ranks well and, on its own, it misleads. The queryzzzz nonexistent capability qqqq scores 100, because something always comes first.

So every search response carries one absolute number beside the relative ones:

"queryMatch": {
  "coverage": 0.0,
  "confidence": "none",
  "matchedTerms": [],
  "queryTerms": ["zzzz", "nonexistent", "capability", "qqqq"],
  "note": "each result's `score` is relative to the best hit in this response ..."
}

coverage is the fraction of the query's content words that the top result's own textaccounts for. It is corpus independent, which is the property the score cannot have, so itseparates "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 thatdoes the opposite thing still scores 1.0. Treat it as a floor on confidence, never as averdict, 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 averified 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, thespecification 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 animplementation detail:

curl -s 'https://neuronto.com/tools?q=extract+text+from+a+pdf&limit=5'

Every tool returned was read from that server's own tools/list. The same search isavailable to agents as the MCP tool find_tool, alongside find_resource,registry_stats and publish_resource. Only publish_resource writes, and it is the onlyone declaring readOnlyHint: false, so a client can tell from the tool list alone whichcall has an effect.

Measuring whether any of this works

GET /bench publishes ARD-Bench, a head to head retrieval measurement across the publicARD registries. Ground truth is the publishers' own representativeQueries, so nothing ishand labelled, and the harness is app/bench.py in this repository.

The response separates two things that are easy to confuse: coverage, whether a registryindexes the target at all, and recall@k_when_carried, whether it retrieves the targetwhen it does hold it. It also states its own known bias, and it reports the results thatdo not flatter us. In the current run, federated search scores slightly below lexical onlyand costs far more latency.

Who publishes an ARD manifest

GET /adoption tracks adoption of the specification itself: a named watchlist oforganisations, and the manifest rate across every host the crawler has seen. At the timeof 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 olderai-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.jsonlcarries 7,708 introspection results including the auth requirement and failure kind. Itexists because tool-retrieval research (ToolRet, ACL Findings 2025) has been benchmarked onassembled 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 yourserver returned to tools/list, and whether the endpoint answers.

[![Neuronto verified tools](https://neuronto.com/badge/your.publisher.id.svg)](https://neuronto.com/console?domain=your.publisher.id)

The publisher id is the publisher segment of your URN, or your domain. The badge is astatement about what was observed, never a trust, safety or quality rating. Not indexedyet? Publish a manifest and the crawler will find you, or run theconsole audit.

Publishing your own resources

Four ways in, in ascending order of effort. There is no allowlist and no signup for anyof them.

You already run an MCP server. Submit the endpoint. Neuronto completes an initializehandshake and reads the server's own tools/list, which is stronger evidence than amanifest claim because the server answered for itself.

curl -X POST https://neuronto.com/submit \
  -H 'content-type: application/json' \
  -d '{"endpoint":"https://example.com/mcp"}'

You are working inside an agent. The same thing as an MCP tool, so a resource can belisted from inside a conversation without leaving it.

{"method":"tools/call","params":{"name":"publish_resource",
 "arguments":{"endpoint":"https://example.com/mcp"}}}

It verifies rather than trusts, exactly as the HTTP route does, and calls that route ratherthan reimplementing it so the two cannot drift apart.

You have no manifest and do not want to write one. Ask for one to be generated fromwhat your domain already exposes, and either copy it or link it.

curl -X POST https://neuronto.com/manifest/build \
  -H 'content-type: application/json' -d '{"domain":"example.com"}'

Only resources that actually answered become entries, and each carries the evidence thatproduced it. The hosted copy at https://neuronto.com/m/example.com.json says in its ownresponse 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 waitfor the crawler.

curl -X POST https://neuronto.com/submit \
  -H 'content-type: application/json' -d '{"domain":"example.com"}'

Serve it at /.well-known/ai-catalog.json as well. Version 0.91 of the specificationrenamed the file, but the deployed base has not moved: of the ARD publishers verified sofar, the large majority still serve only the older path, so a consumer that checks one namemisses most of the ecosystem.

Include representativeQueries on every entry. It is the term registries build theirsemantic index from, and an entry without it is a valid catalogue entry that nosearch will ever return.

Checking whether it worked

curl -X POST https://neuronto.com/audit \
  -H 'content-type: application/json' -d '{"domain":"example.com"}'

Reports whether the manifest is reachable on each of the four discovery paths, whether itsatisfies the specification entry by entry, which registries actually return you, andwho is returned instead of you for the queries you asked to be found for, with whatthose entries have that you may not. Free, no signup. There is a browser version at/console.

Private entries

An organisation can register the internal services its own agents may call, and searchacross public and internal resources in one query.

# 1. ask for the proof record, publish it as a TXT record at your apex
curl -X POST https://neuronto.com/claim \
  -H 'content-type: application/json' -d '{"domain":"example.com"}'

# 2. verify, which returns an API key
curl -X POST https://neuronto.com/claim/verify \
  -H 'content-type: application/json' -d '{"domain":"example.com"}'

# 3. register an internal service
curl -X POST https://neuronto.com/private/entries \
  -H "authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{"entry":{"displayName":"Staff Directory","url":"https://internal/mcp",
       "description":"Look up an employee record by name or badge number.",
       "representativeQueries":["look up an employee record"]}}'

# 4. the same key on search admits them, alongside public results
curl -X POST https://neuronto.com/search \
  -H "authorization: Bearer $KEY" -H 'content-type: application/json' \
  -d '{"query":{"text":"look up an employee record"}}'

The proof value is derived from the domain and never changes, so asking again does notinvalidate a record already published. It is read over DNS over HTTPS, so it verifies assoon 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. Privateentries are never ranked against public ones by corpus statistics, because a single tenant'sindex is too small for those statistics to mean anything; they are placed by how much of thequery their own text accounts for, which means the same thing at any size.

Specification

• Agentic Resource Discovery, v0.91
• ards-project/ard-spec

Licence

Apache-2.0