The Agent Discovery Protocol Race: ARD vs MCP Registry vs A2A Agent Cards
Marketplaces and directories can help humans browse. The next agentic web needs machines to discover capabilities, verify publishers, understand permissions, and test whether an endpoint actually works. This is the race to become its discovery and trust layer.
What Matters
Discovery is becoming a trust problem
A listing tells an agent that something may exist. It does not prove who controls it, whether its claims are current, what it can access, or whether it completes tasks reliably.
No single layer wins everything
ARD, MCP registries, A2A Agent Cards, marketplaces and directories solve different parts of the journey. The durable stack will combine publication, indexing, description, commerce and independent verification.
Measure execution, not inventory
The DN Discovery and Verification Index adds the missing evidence layer: identity, freshness, security transparency, endpoint availability and repeatable task performance.
The Category Error Distorting the Race
ARD, the official MCP Registry, A2A Agent Cards and agent marketplaces are often discussed as if they were competing directories. They are not equivalent. One is a cross-protocol discovery specification, one is a centralized metadata repository for public MCP servers, one is a self-description document for an A2A endpoint, and the others are commercial or editorial interfaces built for distribution.
The distinction matters because the agentic web has at least five separate jobs to perform:
- Publish: let a provider declare what resources it controls.
- Describe: express capabilities, endpoints, authentication and supported interfaces in machine-readable form.
- Index: aggregate resources so clients can search across providers.
- Transact: package access, pricing, billing, support and distribution.
- Verify: independently test identity, availability, permissions and successful execution.
Most systems are strong in one or two of these jobs. The strategic winner may therefore be a stack, not a destination website.
ARD vs MCP Registry vs A2A Agent Cards vs Marketplaces
| Layer | Primary unit | Discovery model | Identity or trust basis | What it does well | What it does not prove |
|---|---|---|---|---|---|
| ARD | Cross-protocol resources in ai-catalog.json | Authoritative domain publication plus federated registry indexing | Domain control with optional verifiable trust metadata | Unifies MCP servers, A2A agents, OpenAPI tools and nested catalogs | That every claim is current, safe or execution-proven |
| MCP Registry | Public MCP server metadata in server.json | Central official repository exposed through an API to aggregators | Namespace authentication through GitHub, DNS or HTTP challenges | Standardized publishing, installation and configuration metadata | Code safety or service quality. The registry delegates scanning and curation |
| A2A Agent Card | One A2A agent endpoint and its skills | Direct fetch from /.well-known/agent-card.json or curated registries | HTTPS and optional JWS signatures | Describes interfaces, capabilities, skills and authentication requirements | That the declared skills perform accurately under real workloads |
| Marketplace | Commercial listing or deployable product | Central browse, search and recommendation interface | Platform review, account identity, ratings or partner checks | Distribution, billing, packaging, reviews and support | Cross-market completeness or protocol-neutral comparability |
| Directory | Editorial or submitted listing | Human-readable categories and search | Varies from self-submission to editorial review | Fast discovery, SEO, use-case education and broad awareness | Ownership, freshness, endpoint health or repeatable execution unless explicitly tested |
1. ARD: A Candidate DNS Layer for Agentic Capabilities
Google introduced the open Agentic Resource Discovery specification in June 2026. Under ARD, an organization publishes an ai-catalog.json file at a well-known path on its own domain. The catalog can describe MCP servers, A2A agents, OpenAPI tools and nested catalogs. Federated registries can index those catalogs while a client can still fetch the publisher's authoritative record directly.
This is ARD's most consequential design choice. Authority begins with the provider's domain rather than a single marketplace account. The model resembles the open web: publishers host canonical metadata, independent indexes organize it, and clients connect through the resource's native protocol.
ARD also contemplates cryptographic trust metadata. That can help a client verify that a catalog originates from the claimed publisher before connecting. Yet publisher authenticity and operational quality remain different questions. A signed catalog can faithfully communicate a bad configuration, an excessive permission request or an unavailable service.
ARD's strategic advantage
ARD is protocol-spanning. It can become the connective tissue above MCP, A2A and conventional APIs rather than another isolated registry.
ARD's adoption risk
Its value depends on publishers maintaining catalogs, registry operators crawling them, and clients consuming the metadata. An open specification can be architecturally elegant and still lose distribution to a default embedded inside a dominant platform.
2. MCP Registry: Standardized Supply for a Large Tool Ecosystem
The official MCP Registry describes itself as a centralized metadata repository for publicly accessible MCP servers. Publishers submit standardized server.json metadata containing identity, package or remote location, execution instructions and discovery information. Its REST API is designed primarily for downstream aggregators, including marketplaces.
That architecture makes the registry a supply rail rather than the final storefront. The official documentation explicitly says metadata is deliberately unopinionated and expects downstream aggregators to add ratings, curation or other information. It verifies namespace control through GitHub, DNS or HTTP challenges, but delegates code scanning to package registries and additional security checks to aggregators.
This separation is healthy, but easy to misunderstand. Namespace authentication can establish who is entitled to publish under a name. It does not establish that installing or invoking the server is safe, that its permissions are proportionate, or that its output is dependable.
MCP Registry's strategic advantage
It gives a rapidly expanding protocol ecosystem one consistent publication format, API and namespace model. Marketplaces can ingest the supply without inventing incompatible submission systems.
MCP Registry's constraint
It is MCP-specific and focused on public resources. Cross-protocol discovery, private enterprise catalogs and independent execution testing sit elsewhere.
3. A2A Agent Cards: The Endpoint's Machine-Readable Passport
The A2A specification defines an Agent Card as the discovery document for an A2A agent. A public card can be served from /.well-known/agent-card.json and describe supported protocols, authentication requirements, interfaces, capabilities and skills. Authenticated clients may retrieve an extended card with additional information.
A2A 1.0 also supports optional Agent Card signing with JSON Web Signatures. Clients can verify a signature against a canonicalized payload and should reject expired or revoked keys. This gives Agent Cards a stronger integrity path than an unsigned promotional listing.
But an Agent Card is still a provider assertion. It is closer to a passport or technical prospectus than an audit. It tells a client how an agent represents itself and how to communicate with it. Only observed execution can determine whether the agent completes a task correctly, reliably and within acceptable cost and latency.
A2A Agent Cards' strategic advantage
They sit close to runtime. A client can discover how to interact with an agent and select an interface without relying entirely on a centralized storefront.
Their limitation
Individual cards do not automatically create global search, commercial distribution or independent quality assurance. Those require registries, marketplaces and verification services.
4. Marketplaces and Directories: Distribution Is Not Verification
Marketplaces and directories remain essential. Humans need categories, comparisons, examples, reviews and onboarding. Developers need billing, deployment and support. Vendors need acquisition. A protocol document cannot replace those functions.
The danger is confusing inventory size with intelligence. A directory can grow quickly by accepting self-submitted entries, importing repositories or indexing protocol registries. That creates coverage, but also stale records, duplicate agents, ambiguous ownership and inflated capability claims.
The best marketplaces will ingest ARD catalogs, MCP Registry metadata and A2A Agent Cards, then add commerce and governance. The best intelligence platforms will go further by testing the claims.
The DN Discovery and Verification Index
The DN Discovery and Verification Index, or DN-DVI, is a 100-point methodology for evaluating whether an agentic resource is merely listed or genuinely ready for selection and execution. It separates evidence about the publisher from evidence about the endpoint.
| Dimension | Weight | Evidence DN looks for | Why it matters |
|---|---|---|---|
| Publisher identity | 15 | Authoritative domain, verified namespace or valid cryptographic signature | Links the resource to an accountable publisher |
| Discovery coverage | 10 | Authoritative catalog plus one or more compatible registries | Reduces dependence on one index or interface |
| Metadata completeness | 15 | Stable identifier, version, capabilities, endpoint, auth, inputs and outputs | Makes machine selection and integration possible |
| Freshness and lifecycle | 15 | Recent verification, version history, deprecation and status signals | Prevents clients choosing abandoned or superseded resources |
| Endpoint availability | 15 | Successful discovery fetch and connection tests across time | Distinguishes operational services from dead listings |
| Security transparency | 10 | Permissions, data handling, auth scopes, incident channel and security record | Exposes risk before installation or connection |
| Execution evidence | 15 | Repeated task tests measuring completion, accuracy, latency and failure behavior | Tests whether claims survive contact with real work |
| Commercial transparency | 5 | Pricing unit, fees, quotas, refunds, paid endpoint status and support terms | Allows agents and humans to estimate total cost |
Non-negotiable trust gates
- Verified: requires evidence of publisher or namespace control.
- Operational: requires a live endpoint test, not a successful metadata fetch alone.
- Execution-Proven: requires repeated successful task runs with disclosed test conditions.
These gates prevent a resource from compensating for missing identity or failed execution with polished documentation and broad distribution.
DN Agent Discovery and Verification Scorer
Select only claims you can support with current evidence. The tool calculates a preliminary DN-DVI score and applies the trust gates.
Listed
Trust status: unverified publisher. Do not automate connection.
Screening tool only. A high score is not a security certification, investment recommendation or guarantee of performance.
How to Read the Score
| Score | DN status | Interpretation |
|---|---|---|
| 0 to 24 | Listed | Basic existence claim. Insufficient evidence for automated selection. |
| 25 to 44 | Described | Some usable metadata, but material identity, freshness or operational gaps remain. |
| 45 to 64 | Discoverable | Machine-readable and findable, but not necessarily verified or live. |
| 65 to 79 | Verified | Publisher control must be established. Security and execution evidence may still be incomplete. |
| 80 to 89 | Operational | Publisher and endpoint gates pass. Suitable for controlled testing with least privilege. |
| 90 to 100 | Execution-Proven | Identity, availability and repeatable execution gates pass under disclosed test conditions. |
The Architecture Most Likely to Win
The most resilient discovery stack is layered:
- Authoritative publication: a provider hosts an ARD catalog and its endpoint-specific descriptors.
- Protocol registration: MCP resources publish standardized metadata; A2A agents expose Agent Cards.
- Federated indexing: independent registries crawl authoritative sources and normalize search.
- Commercial distribution: marketplaces add billing, deployment, contracts and support.
- Independent intelligence: DN measures freshness, permissions, availability, price and execution quality.
This model avoids two dangerous monopolies. Publishers do not become trapped inside one marketplace, and clients do not have to trust self-description without independent evidence.
The DN Alpha Thesis: Verified Capability Is the Scarce Asset
Agent listings will become abundant. Automated crawlers can already generate enormous catalogs. Metadata itself will increasingly be standardized. The scarce asset will be trustworthy evidence that a specific capability works now, for a defined task, at an acceptable risk and price.
That shifts value toward five data products:
Freshness graph
Tracks version, endpoint, ownership, deprecation and last successful verification across protocols.
Capability benchmark
Runs comparable tasks and records completion, accuracy, latency, cost and recovery behavior.
Permission map
Normalizes requested scopes, data access and downstream dependencies before connection.
Price intelligence
Converts subscriptions, token pricing, x402 payments, fees and quotas into task-level cost.
Publisher graph
Connects domains, namespaces, signing keys, repositories, organizations and incident histories.
Compatibility matrix
Shows which clients, registries, transports, auth schemes and payment rails work together.
For Decentralised News, this is a path from publication to infrastructure. Articles acquire search demand. The index creates proprietary data. The scorer generates qualified leads. An API, verified profile program, benchmark sponsorship and enterprise intelligence feed can monetize the dataset without compromising editorial rankings.
What Builders, Buyers and Publishers Should Do Now
| Role | Priority action | Reason |
|---|---|---|
| Agent or tool publisher | Publish authoritative machine-readable metadata under a domain you control | Preserves portability and establishes an accountable source of truth |
| MCP server developer | Use standardized registry metadata and verify the namespace | Makes downstream marketplace ingestion easier without implying security certification |
| A2A provider | Expose a current Agent Card, use HTTPS and sign cards where practical | Improves integrity and automated client selection |
| Marketplace | Ingest open metadata, but publish independent freshness and security signals | Raw inventory is easy to copy. Trusted evidence is defensible |
| Enterprise buyer | Pin approved versions and retest endpoints, permissions and outcomes | Discovery metadata can change after initial review |
| Agent client | Separate discovery from authorization and use least privilege | Finding a capability should never imply permission to invoke it |
What Would Prove This Thesis Wrong?
The layered-stack thesis would weaken if one platform achieved dominant client distribution and bundled publisher verification, protocol translation, billing, continuous security scanning and execution benchmarks so effectively that open discovery became irrelevant. It would also weaken if buyers consistently chose agents on brand alone and showed little willingness to pay for independent verification.
DN will watch three falsification signals: concentration of agent connections in one closed marketplace, low adoption of domain-hosted catalogs and signed descriptors, and an absence of measurable demand for freshness or execution evidence. Until those appear, open publication plus independent intelligence is the more resilient model.
DN-DVI Methodology and Evidence Boundaries
Version: 1.0, published September 21, 2026. The weights reflect DN's editorial assessment of what most affects safe discovery and selection. They are not an industry standard.
Scoring: Reviewers should preserve evidence snapshots, record the date and method of each test, and score only public or permissioned evidence they can reproduce. Partial compliance should be documented rather than rounded upward. Critical gates override the numerical tier.
Execution testing: A successful run means the resource completed a defined task within stated constraints. It does not generalize to all prompts, environments, data classes or adversarial conditions.
Update policy: Scores should be refreshed after material version, ownership, endpoint, pricing, permission or incident changes, and at least quarterly for active resources.
Primary Sources
- Google Developers Blog: Announcing the Agentic Resource Discovery specification, June 17, 2026.
- Agentic Resource Discovery specification.
- Model Context Protocol: The MCP Registry, accessed September 21, 2026.
- Official MCP Registry, accessed September 21, 2026.
- A2A Protocol Specification 1.0, including Agent Discovery and Agent Card Signing.
- A2A Protocol open-source project.
Frequently Asked Questions
Is ARD a replacement for MCP?
No. ARD is a discovery layer that can describe and index MCP servers, A2A agents, OpenAPI tools and other resources. MCP defines how AI applications connect to tools and context.
Is the MCP Registry a marketplace?
Not in the full commercial sense. It is an official metadata repository and supply source for public MCP servers. Its documentation expects downstream aggregators and marketplaces to add curation, ratings and other services.
What is an A2A Agent Card?
It is a machine-readable description of an A2A agent's interfaces, capabilities, skills and authentication requirements. A public card can be exposed at a standardized well-known URL.
Does a signed Agent Card prove an agent is safe?
No. A valid signature helps prove integrity and origin. It does not prove safe code, proportionate permissions, accurate output or reliable execution.
What does DNS or domain verification prove?
It can prove that a publisher controls the relevant namespace or domain. It does not prove every capability claim made under that identity.
Why are marketplaces still needed?
They add human discovery, packaging, deployment, billing, contracts, support and sometimes curation. These are commercial functions that protocol descriptors do not provide by themselves.
What is the biggest weakness of agent directories?
Freshness. Listings can remain searchable after endpoints fail, ownership changes or products are abandoned. A serious directory needs timestamps, lifecycle data and recurring tests.
What is the DN Discovery and Verification Index?
DN-DVI is Decentralised News' 100-point framework for measuring identity, discovery coverage, metadata, freshness, availability, security transparency, execution evidence and commercial clarity.
Can a resource score highly without execution tests?
It can score well on metadata and identity, but it cannot receive DN's Execution-Proven status without repeated successful task tests under disclosed conditions.
What should enterprises verify before allowing an agent to connect?
Confirm publisher identity, endpoint ownership, authentication method, requested scopes, data handling, version, dependency chain, incident channel and performance on controlled test tasks.
