Compare

ARD vs MCP

They get compared constantly and they are not alternatives. One finds the tool, the other talks to it.

MCP is how an agent calls a tool. ARD is how it finds one. ARD runs before invocation and hands off to the resource's own protocol, so an MCP server discovered through ARD is still spoken to over MCP. They are complementary layers, and MCP servers are the largest single category in every public ARD index: 8,714 of 14,732 entries in ours.

The one-sentence version

MCP is a protocol for using a tool. ARD is a protocol for finding one. Confusing them is easy because both are recent, both involve JSON on a well-known path, and both were announced with the word "agents" in the headline. But they never do the same job, and neither can do the other's.

	ARD	MCP
Question it answers	Which capability fits this task, and where is it	How do I call this capability
When it runs	Before invocation. Discovery only.	During invocation. Every call.
What you publish	A manifest at `/.well-known/ard.json` describing resources	A server exposing tools over the MCP transport
Who reads it	Registries, and clients querying registries	The agent, at call time
Shape	A JSON document plus `POST /search`	A JSON-RPC session
Scope	Any agentic resource: MCP, A2A, skills, OpenAPI, other registries	MCP servers only
Governance	Working group with Google, Microsoft, Hugging Face, GoDaddy. Apache 2.0.	Anthropic, open source

How they fit together

The specification is explicit that ARD steps out of the way once it has answered:

ARD sits entirely before invocation. It helps the client find the right resource; the resource is then invoked through its own native mechanism.
ARD specification v0.91, the specification homepage agenticresourcediscovery.org

So a full round trip looks like this. The agent needs to do something. It asks a registry, in plain language. The registry returns entries, one of which is an MCP server with a URL. The agent opens an MCP session to that URL and gets on with it. ARD is not in the session and never sees the traffic.

discover once, then speak MCP

# 1. discovery, once, when the agent realises it needs something
POST https://any-ard-registry/search
{ "query": { "text": "extract line items from a scanned invoice" } }

# 2. the registry answers with candidates
{ "results": [ {
    "identifier": "urn:air:acme.com:server:invoices",
    "type": "application/mcp-server-card+json",
    "url": "https://api.acme.com/mcp",
    "score": 91 } ] }

# 3. invocation, over MCP, directly. ARD is done.
POST https://api.acme.com/mcp   { "method": "tools/call", ... }

Why this matters more than it sounds

Because of the context window. An agent that hardcodes its MCP servers must load every tool description into context on every request, whether or not this request needs any of them. That is the problem ARD was written for, and it is the reason discovery is a separate layer rather than an MCP feature.

The practical effect is that adding a capability stops being a code change. Your agent asks for what it needs, gets back three candidates instead of the ninety it might have had wired in, and pays context for three.

What this means for you

If you	Then
Run an MCP server nobody has found	Publish an ARD manifest with one entry pointing at it. One file, no code change. Five minutes.
Build an agent with hardcoded servers	Query a registry at the point of need instead. Your tool list stops being a build-time decision. How to wire it up.
Run an MCP directory	Expose `POST /search` and you are an ARD registry. Your list becomes queryable by every ARD client rather than only by people visiting your site.

Get indexed

If you already run an MCP server, one manifest and one call is the whole distance between it and being discoverable.

one call, any ARD registry that accepts submissions

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

Disclosure: Neuronto is run by the people who write this site, and it is named first for that reason as much as any other. It resolves a bare domain to your manifest, indexes entries of every type rather than MCP servers only, and answers with what it found or exactly what it tried. Add "dry_run": true to see the outcome without being written anywhere.

The other public registries take submissions through their own doors, and submitting to several costs nothing: WellKnown, ARD Registry Hub, Desvela. What actually reaches all of them over time is the manifest on your own domain, which is the part nobody can take away from you. How each one behaves, probed.

Questions

Does ARD replace MCP?

No. They solve different halves of the same sentence. MCP is how an agent calls a tool; ARD is how it finds one worth calling. You use both.

Do I need ARD if I already have an MCP server?

Only if you want people to find it without being told about it. An MCP server with no ARD entry works perfectly for anyone who already has your URL, and is invisible to everyone else.

Is MCP being deprecated in favour of ARD?

No, and nothing suggests it. MCP servers are the largest resource family in every public ARD index by a wide margin: 8,714 of 14,732 entries in ours.

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