Data

ARD registries, compared

Same four requests against every public registry, on the same day, with the script published.

6 of 6 public ARD registries answer POST /search, which is the only endpoint the specification requires. 5 serve it at the path the spec names; one serves it at /api/search, where a conformant client cannot find it. 2 publish an ARD manifest of their own, and 1 answers all four surfaces. Probed 4 September 2026.

What was measured

Every public ARD registry we know of, probed on 4 September 2026 with the same four requests: the search endpoint, POST /explore, GET /agents, and a well-known manifest at the root. Plus one extra: a GET against the search endpoint, where the correct answer is 405 and a 404 is a bug with real consequences.

Registry	POST search	At the spec path	Latency (ms)	/explore	/agents	well-known	GET on search
Neuronto neuronto.com	200	yes	1,162	200	200	200	405
GitHub Agent Finder agentfinder.github.com	200	yes	1,983	400	200	404	405
WellKnown wellknownhq.com	200	yes	609	200	404	404	405
Desvela ARD Registry registry.desvela.dev	200	yes	390	400	404	200	404
ARD Registry Hub ardregistry.org	200	/api/search	1,853	404	404	404	400
Hugging Face Discover huggingface-hf-discover.hf.space	200	yes	2,254	501	404	404	405

What the table says

Everyone answers search. Almost nobody does the rest.

That is the correct outcome, to be fair to everybody in the table: POST /search is the only endpoint the specification requires, and /explore and /agents are explicitly optional. A registry that serves search and nothing else is fully conformant.

One registry does not serve search where the specification says

ARD Registry Hub serves search at /api/search rather than /search. It works, and it returns results, but a conformant client that has only its base URL cannot find it, which undercuts the guarantee that makes federation possible. We federate it anyway by hardcoding the path, which is exactly the manual wiring ARD exists to remove.

Two registries publish a manifest of their own

A registry is itself an agentic resource, typed application/ai-registry+json, and section 5.3 says a registry's operational base URL is discovered by finding entries of that type. So a registry with no manifest cannot be discovered by the mechanism it implements. Most do not have one. Neither does the specification's own website.

The 404-instead-of-405 bug is everywhere, including here

A POST-only route that answers a GET with 404 tells an SDK client the endpoint does not exist, so it stops rather than retrying with the right verb. One registry in this table gets it wrong. So did we, for two days, at a cost of zero completed tool calls while everything looked fine from the inside.

Disclosure. Neuronto is in this table and we run it. It comes out well on conformance, which is a fair thing to be suspicious of. The probe script is published above the table's data file and runs the same four requests against every host; run it yourself if you want. Latency is a single sample from one location on one day and should not be read as a service quality measure.

Reproducing this

One request per surface, no authentication, twelve second timeout.

the probe, in two commands

curl -s -o /dev/null -w "%{http_code}\n" -X POST \
  -H "Content-Type: application/json" \
  -d '{"query":{"text":"scrape a web page"},"pageSize":3}' \
  https://<registry>/search

# the one people get wrong: GET on a POST-only route should be 405, never 404
curl -s -o /dev/null -w "%{http_code}\n" https://<registry>/search

If you run a registry

Serve search at /search. If you need a different internal path, alias it.
Answer 405 on the wrong verb, never 404.
Publish your own /.well-known/ard.json with an application/ai-registry+json entry, so clients can discover you the way the spec describes.
/explore is optional but cheap if you already have facets, and it is the only way a client can ask what you contain before asking for something specific.

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