2026 Comparative Analysis: Federated Resource Discovery Infrastructure for AI Agents — Applied Technology Index

Executive Summary

Federated agentic resource discovery is the process of finding agents, MCP servers, skills, APIs, and other callable services across independently operated catalogs without pre-installing every resource or copying every description into a model context. It sits before tool loading and invocation: discovery produces candidates and metadata; a client still has to verify, authorize, connect to, and evaluate the selected resource.

The Agentic Resource Discovery specification, or ARD, is the clearest current proposal for a protocol-neutral discovery layer. ARD v0.91 defines a JSON-LD entry model, domain-anchored identifiers, a publisher manifest at /.well-known/ard.json, semantic and structured search through POST /search, and three federation modes. It can describe an A2A agent, MCP server, skill, API, registry, or future artifact by using a media type and either an inline value or URL reference.

The important distinction is that ARD does not replace the systems around it:

A2A Agent Cards describe and connect to a particular remote agent; A2A also standardizes messages, tasks, artifacts, streaming, polling, and webhooks after discovery.
The official MCP Registry is a protocol-specific public metaregistry for MCP server metadata and package references.
AWS Agent Registry is a managed, private governance product with IAM or JWT authorization, approval workflows, record lifecycle, hybrid search, cross-account sharing, and MCP access.
Hugging Face Discover is an implementation that maps existing Hub resources into ARD results and demonstrates searchable skills and MCP servers.
ARD is an open envelope and search/federation contract intended to connect catalogs across those boundaries while leaving execution to each resource’s native protocol.

ARD’s main architectural contribution is to separate the known resource universe from the model-visible tool set. A registry can search a much larger index using natural language, structured filters, publisher identity, artifact type, and extension metadata. The client can then admit a small verified subset into its normal tool-search or execution pipeline. This is different from searching only the tools already declared to a model provider.

Its largest unresolved issue is trust interoperability. ARD can carry a trustManifest, requires its identity domain to align with the publisher domain in the entry identifier, and explicitly separates relevance from trust. However, v0.91 does not define one universal signature, canonicalization, key-resolution, attestation, revocation, or reputation system. The declared trust framework supplies those procedures. Two registries can therefore exchange structurally compatible entries while applying materially different verification and admission policies.

ARD v0.91 is also a proposal, not a stable production standard. Its August 2026 revision changed the normative well-known path from the predecessor /.well-known/ai-catalog.json to /.well-known/ard.json, reframed entries through JSON-LD namespaces, and documents community media types that are not yet fully registered with IANA. Early implementers need version pinning, dual-path migration where useful, schema validation, provenance retention, and explicit compatibility tests.

Key findings

Discovery is not invocation. ARD finds candidate resources. MCP, A2A, HTTP APIs, package installers, or framework-specific loaders perform connection and execution.
Discovery is not authorization. A matching entry does not mean the current user, agent, tenant, or task may invoke it. Eligibility must be checked before search and again at execution.
A relevance score is not a trust score. ARD normatively states that its 0–100 search score represents semantic relevance only.
Federation changes the threat model. auto federation gives the queried registry responsibility for upstream selection and result merging; referrals gives the client visibility and control over which additional registries to query; none confines discovery to one index.
Publisher-controlled web discovery reduces repeated registration. The same domain-hosted entry can be indexed by several registries, but only if crawlers find it, parse it consistently, and preserve source provenance.
Protocol-specific metadata remains necessary. An ARD result can point to an A2A Agent Card or MCP server card, but it cannot substitute for the complete native descriptor, compatibility negotiation, or execution contract.
Private curation and open federation are complementary. AWS Agent Registry can govern an approved internal inventory while ARD supplies an interoperability layer for cross-environment discovery. AWS describes that relationship as an expected direction; its August post says support for open discovery standards is still evolving.
Searchable metadata becomes operational code. Descriptions, representative queries, tags, capabilities, media types, publisher identifiers, and extension fields influence which executable resource reaches an agent.
Version drift is already material. Current ARD v0.91 uses ard.json; launch-era materials and predecessor implementations refer to ai-catalog.json. Consumers cannot assume every public example reflects the current proposal.
The safe architecture is policy-filtered federation. Query only trusted registries, preserve the source of each result, verify publisher authority, apply local admission policy, fetch and validate the native descriptor, and expose only the smallest eligible subset to the model.

Methodology

This analysis reviewed primary and technical materials available on 8 September 2026. The live Applied Technology Index research index and local public content collection were checked before topic selection. Existing ATI work covered MCP registries and gateways, dynamic tool loading, A2A delegation, authorization, skills packaging, and tool provenance, but not the newly specified cross-registry discovery and federation layer introduced by ARD.

Current developer and vendor discussion was used only for signal discovery. X search was attempted but unavailable because the configured provider had reached its spending limit. The publication decision instead relied on the August 2026 ARD v0.91 revision, AWS’s public description of ARD and the general availability of AWS Agent Registry, A2A v1.0, and the Hugging Face Discover implementation. Factual claims are grounded in the ARD specification repository, official AWS documentation and announcements, the official MCP Registry repository, the A2A specification, and Hugging Face’s technical materials.

The approaches were assessed on eleven criteria:

Discovery scope: one known endpoint, one protocol ecosystem, one cloud account or organization, one public platform, or federated registries.
Publication model: well-known web manifest, direct registry submission, synchronized URL, generated adapter record, or endpoint-local metadata.
Resource types: agents, MCP servers, skills, APIs, packages, custom records, registries, or protocol-specific resources.
Search model: exact listing, semantic search, keyword search, structured filtering, hybrid retrieval, or client-side federation.
Federation: centralized aggregation, subregistry ingestion, automatic upstream search, referrals, or no federation contract.
Identity and trust: namespace ownership, domain binding, signatures, trust-manifest interpretation, approval, source provenance, and local policy.
Authorization: public access, cloud IAM, JWT, OAuth, registry visibility policy, or native endpoint authentication.
Lifecycle: record versioning, approval, rejection, deprecation, synchronization, cache invalidation, and revocation.
Invocation handoff: URL or inline descriptor, package reference, MCP tool, A2A interface, API specification, or another native mechanism.
Auditability: source registry, query, filters, relevance score, verification outcome, selected descriptor, authorization, and invocation evidence.
Maturity: proposal, preview, generally available managed product, stable protocol release, or reference implementation.

This is a documented-capability and architecture comparison. No common search corpus, live federated registry mesh, malicious-entry set, ranking benchmark, latency test, compatibility suite, or production procurement exercise was run across all systems. The article does not independently verify vendor search quality, registry scale, uptime, security, or adoption.

Comparative Analysis Table

Approach	Discovery boundary and resource types	Search and federation model	Trust and governance	Invocation handoff	Maturity and main limitation
ARD v0.91	Artifact-agnostic entries for agents, MCP servers, skills, APIs, registries, and future media types across publisher domains	REST `POST /search` with semantic text, structured filters, pagination, and `auto`, `referrals`, or `none` federation; optional `POST /explore` and `GET /agents`	Domain-anchored `urn:air:` identifier; optional open `trustManifest`; publisher-domain alignment required when trust identity is present; verification delegated to the declared trust framework	Returns an inline artifact or URL reference; native protocol performs connection and execution	Proposal dated 26 August 2026; trust procedures and reputation are not unified; path and data-model evolution create compatibility work
AWS Agent Registry	Private registries containing `AGENT`, `MCP`, `SKILL`, or `CUSTOM` records within AWS accounts and shared organizations	Hybrid semantic and keyword search, browse and batch-get APIs, approved-record filtering, MCP endpoint; AWS presents ARD as a complementary future cross-environment layer	IAM or JWT inbound authorization, manual or automatic approval, status lifecycle, CloudTrail, EventBridge, tags, cross-account sharing, infrastructure as code	Full record descriptors point to A2A, MCP, skill, or custom definitions; consumers connect through the relevant runtime	Generally available in five regions as of 31 August 2026; proprietary service boundary and an active namespace/API migration through 17 September 2026
Official MCP Registry	Public MCP servers represented by `server.json`; metadata references packages or remote servers	Canonical public metaregistry plus ecosystem subregistries that ingest and add curation; protocol-specific API rather than artifact-agnostic federation	Publishing verifies GitHub or domain namespace ownership; downstream catalogs add review, ratings, or policy	Client obtains package, runtime, transport, environment, and version metadata, then installs or connects through MCP	Public registry is still described as preview/API-freeze in repository materials; covers MCP servers rather than arbitrary agentic resources
A2A Agent Card v1.0	A single remote A2A server publishes identity, skills, capabilities, interfaces, and security requirements	Well-known or known-endpoint card discovery; no general cross-publisher search index or registry-federation algorithm in the core interaction specification	Security schemes describe how to authenticate; v1.0 adds signed Agent Cards, but a card still does not certify service quality or authorization for a task	Direct handoff into A2A messages, tasks, artifacts, polling, streaming, or push notifications	Released protocol for agent-to-agent interaction; endpoint-level discovery must be indexed by another system for open-ended search
Hugging Face Discover	Hub-hosted and indexed skills, Spaces, and MCP-tagged resources translated into ARD entries	ARD-compatible REST and MCP discovery over existing semantic search; can serve as a concrete registry or federated source	Platform metadata and runtime filters supply useful signals; clients still need publisher, code, permission, and endpoint verification	Results can expose a skill representation, MCP server card, or Space metadata for the client’s native loader	Reference implementation and live integration pattern; coverage and trust inherit the Hub’s data and adapter choices rather than proving universal federation

Observed Profiles

ARD v0.91: a protocol-neutral discovery envelope

ARD defines an entry, not a universal executable package. Each entry must include a globally unique domain-anchored identifier, human-readable display name, media type, and exactly one of url or data. representativeQueries are recommended because they provide examples for semantic indexing; capabilities can support fast filtering. JSON-LD context allows publishers to add domain-specific terms without changing the core specification.

The current normative publication path is https://<publisher>/.well-known/ard.json. ARD also permits in-page JSON-LD, a rel="ard" link, an Agentmap directive in robots.txt, and DNS service-binding records. Registries must support web ingestion and may add repository, package-registry, or OCI ingestion.

The search API combines natural-language intent and structured constraints. A query can require an A2A media type, named capability, publisher, tag, or namespaced compliance field while ranking the matched set by semantic relevance. This creates a stronger retrieval surface than placing thousands of generic descriptions in one prompt, but it moves correctness into registry indexing, schema quality, filter support, and ranking evaluation.

Federation is the distinguishing feature. In auto mode, the first registry queries upstream registries and merges results. In referrals mode, it returns local results plus registry entries the client may follow. In none mode, it searches only itself. Referrals is easier to audit because the client can record each upstream request and apply its own allowlist; auto is simpler for the client but requires confidence in the aggregator’s upstream policy, deduplication, ranking normalization, timeout behavior, and provenance retention.

ARD correctly states that relevance is not trust. A malicious resource can match a task perfectly. The optional trustManifest can carry identity, attestations, provenance, and signatures, and the publisher domain in a trust identity must align with the domain embedded in the entry identifier. Yet verification mechanics belong to the declared trust framework. Operators therefore need a local trust-policy engine that understands approved frameworks, issuers, algorithms, key resolution, freshness, revocation, and required attestations.

AWS Agent Registry: private curation and governed discovery

AWS Agent Registry implements a different control boundary. An organization creates one or more private registries, selects IAM or JWT inbound authorization, publishes typed records, and controls whether submission requires manual approval. Only approved records appear in discoverable APIs. Records can represent A2A agents, MCP servers, skills, or custom JSON resources.

The general-availability service adds browse, semantic and keyword search, batch retrieval, cross-account sharing through AWS Resource Access Manager, tags, infrastructure-as-code support, organizational auto-detection for selected AWS agent resources, and audit/event integrations. The service also exposes discovery through MCP, letting a compatible client search a registry as a tool.

This lifecycle addresses questions ARD intentionally leaves to deployments: who may publish, who curates, which revision remains discoverable, how an entry is hidden or deprecated, and how access is tied to enterprise identity. AWS documents eventual consistency between approval and search indexing, so consumers must not treat an empty immediate search as definitive after a record transition.

AWS’s ARD article presents federation as a complement rather than a completed equivalence claim. It describes a future in which catalogs across clouds, on-premises environments, and SaaS expose a common protocol while local AWS access controls remain enforcement points. The prudent interpretation is that AWS Agent Registry is a concrete governed catalog today, while ARD interoperability should be verified against the exact service release and endpoint before an architecture depends on it.

The August–September 2026 namespace migration is operationally significant. New integrations use the dedicated agent-registry namespace and .api.aws endpoints. Existing public-preview users must migrate records, endpoints, IAM actions, ARNs, SDK clients, CLI commands, and observability integrations before the old bedrock-agentcore registry namespace closes on 17 September 2026. Documentation examples that still show old endpoints need to be read in that migration context.

Official MCP Registry: canonical protocol-specific metadata

The official MCP Registry is a public metaregistry for MCP servers. A server.json record describes identity, package location, runtime, transport, version, and related metadata. The registry points to npm, PyPI, Docker, OCI, or other package locations rather than hosting every binary itself.

Its ecosystem design expects subregistries to ingest canonical public records and add curation, ratings, or enhanced metadata. That is a form of registry composition, but it differs from ARD’s request-time auto and referrals modes. The MCP model is protocol-specific and publication-centered; ARD aims to place MCP servers beside A2A agents, skills, APIs, and registries in one search envelope.

Namespace ownership verification through GitHub, DNS, or HTTP helps prevent straightforward publisher impersonation. It does not establish that a package is safe, a tool description is honest, an endpoint remains controlled by the same operator, or a requested action is authorized. Package signatures, provenance, sandboxing, OAuth, tool policy, and execution receipts remain separate layers.

The two systems can compose. An ARD registry can index an MCP registry entry or produce an ARD entry whose media type points to an MCP server card. The client then retrieves the complete MCP metadata and connects using MCP. Deduplication must preserve both the ARD identifier and native MCP server identity rather than collapsing resources by display name.

A2A Agent Cards: endpoint discovery followed by interaction

A2A v1.0 defines the native contract for interacting with an independently deployed remote agent. An Agent Card describes the agent’s identity, skills, capabilities, interfaces, and security requirements. Once connected, A2A supports direct messages or stateful tasks, artifacts, polling, streaming, push notifications, and version negotiation across JSON-RPC, gRPC, and HTTP/REST bindings.

This gives A2A richer post-discovery semantics than ARD. ARD can find a flight-booking agent and return the Agent Card location; A2A defines how the client submits work and receives the result. Conversely, one Agent Card endpoint does not provide web-scale semantic search across every provider. A registry or crawler must index cards to support open-ended discovery.

A2A v1.0’s signed Agent Cards improve metadata integrity, but signatures answer a bounded question: whether the card is authentic under the relevant key and signature rules. They do not prove task success, safe internal behavior, current authorization, availability, or suitability for the user. An ARD registry should preserve signature evidence and verification time rather than converting a signed card into a generic “trusted” label.

Hugging Face Discover: adapting a live ecosystem to ARD

Hugging Face Discover shows how an existing platform can become an ARD discovery service without replacing its native execution models. The implementation uses Hub search and metadata, filters for running resources where applicable, and can return different artifact representations such as skills, MCP server cards, or platform-native Space metadata.

This validates ARD’s adapter model: discovery normalizes enough metadata for search while type tells the client which loader or protocol should handle the result. It also exposes the practical limits. A generated skill wrapper is not equivalent to source review; a running Space is not a service-level guarantee; an MCP tag is not authorization; and platform search ranking may not reflect an enterprise’s policy, data residency, or risk requirements.

A private enterprise registry can use Hugging Face Discover as an allowed referral or ingestion source, then apply local curation. It should not automatically install or invoke every high-ranking public result. The useful composition is open discovery, local admission, native execution.

A production discovery pipeline

A defensible production design separates nine stages:

Publish: Resource owners expose versioned, machine-readable descriptors under a controlled namespace.
Ingest: Registries crawl or synchronize records while retaining source URL, retrieval time, content digest, and parser version.
Verify: Validate schema, publisher authority, declared trust framework, signatures, provenance, freshness, and revocation status.
Curate: Apply organizational approval, legal, security, quality, region, license, and lifecycle policy.
Search: Query only allowed registries and eligible records; preserve query, filters, federation mode, source, and score.
Resolve: Fetch the complete authoritative entry and native descriptor, then check version and compatibility.
Load: Expose only the smallest relevant, authorized subset to the model or workflow.
Invoke: Authenticate to the resource’s native protocol and authorize the exact operation and arguments.
Verify outcome: Reconcile the returned artifact or side effect against an authoritative external system and record acceptance.

Caches at each stage need different invalidation. A registry search result can remain semantically relevant after its endpoint is revoked. A signed descriptor can remain authentic after its version is deprecated. A previously approved resource can become ineligible for one tenant or task. Cache discovery for efficiency, never as continuing authority.

Minimum evaluation set

Before enabling runtime discovery, test:

exact-name and natural-language queries;
cross-language and domain-specific synonyms;
near-duplicate resources and version families;
unavailable, deprecated, and revoked resources;
malicious descriptions and representative queries;
mismatched publisher domains and trust identities;
valid signatures from unapproved issuers;
stale Agent Cards and changed MCP schemas;
federation loops, duplicate referrals, and unreachable upstreams;
conflicting relevance scores across registries;
unsupported media types and JSON-LD namespaces;
ard.json versus predecessor ai-catalog.json publication;
empty or sparse pages with continuation tokens;
authorization changes between search and invocation;
results that are relevant but prohibited by region, data policy, or license.

Measure candidate recall, loaded-set precision, forbidden-resource exposure, duplicate rate, verification failure rate, stale-result rate, p50 and p99 search latency, upstream timeout rate, model tool-selection accuracy, completed-task cost, and independently verified task success. A larger catalog is not a better catalog if it raises unsafe exposure or makes the correct resource harder to identify.

Limitations

ARD v0.91 is a proposal dated 26 August 2026. Its schemas, media types, well-known path, JSON-LD model, filter semantics, federation behavior, and trust guidance may change. The specification notes that A2A and MCP card media types used in examples are community conventions moving toward IANA registration rather than completed registrations.

Launch materials and implementations can lag the specification. Earlier ARD and AI Catalog documents use /.well-known/ai-catalog.json, while v0.91 makes /.well-known/ard.json normative and predecessor resolution optional. This article follows the current repository source of truth and identifies predecessor behavior only for migration context.

The compared systems are not direct substitutes. ARD is a discovery specification; AWS Agent Registry is a managed governance product; the official MCP Registry is a protocol-specific public metaregistry; A2A is primarily an interaction protocol with endpoint metadata; and Hugging Face Discover is an implementation over one ecosystem. Their inclusion in one table is meant to clarify layer boundaries rather than rank a winner.

No shared corpus or conformance test was executed. Search quality, federation correctness, verification interoperability, throughput, latency, cost, availability, and security outcomes were not independently measured. Provider and project claims are reported as documented capabilities.

Public documentation can change unevenly during product migrations. AWS’s current migration guide establishes the dedicated agent-registry namespace and 17 September 2026 retirement date for the old registry namespace, while some linked developer pages and examples still expose bedrock-agentcore names. Implementers should use the current API reference and migration guide for their exact account and region.

ARD’s trust model is extensible but not self-executing. A trustManifest, domain match, signature, attestation, registry approval, or namespace proof cannot establish software safety, truthful capabilities, operational reliability, legal permission, or authorization for a specific action. Those properties require independent controls and evidence.

Open discovery increases exposure to metadata poisoning, typosquatting, ranking manipulation, stale endpoints, compromised publishers, malicious packages, hidden ownership transfers, and prompt injection. This analysis does not provide a complete threat model or security certification for any implementation.