All posts
· 8 min read ·

Federation overlap: counting Smithery, a2aregistry, Glama, and friends

Eight months of crawling every public agent / MCP registry produces an overlap matrix. The diagonal is mostly empty: registries advertise federation but few publish the same agent. The implications for trust, deduplication, and registry-of-registries are uncomfortable for all parties involved.

The agent ecosystem currently runs at least six public registries claiming federation as a value proposition: Smithery, Glama, PulseMCP, the AAIF Agent Registry, the Linux Foundation a2aregistry, and the Linux Foundation registry. "Federation" here means: each registry promises that the agents it lists can be discovered by callers reaching any of the registries in the network. The Architecture and Federation page on mcp.so, the AGNTCY federation proposal, and the AAIF white paper all use the word in the standard way: a client looking for an agent on registry A should see registries B-F without re-querying.

Eight months of running an empirical cross-walk — Agenstry indexes each registry as a separate source and keeps the per-source provenance row, so we can ask "how many of the agents on registry A also appear on registry B?" — produces an overlap matrix that is worth publishing. The diagonal (agents appearing only on a single registry) is heavy. The cross-cells (agents appearing on multiple registries) are sparse.

What we measured

Each row in our agent_sources table records (agent_domain, source) — the agent's canonical domain plus the registry that surfaced it. For 2,603 distinct agent domains in the index today, the provenance breakdown is:

Source Agents seen Live-rate
agentic_market (Coinbase) 798 0.9 %
mcp_registry (LF) 718 2.9 %
lists (community curation) 444 1.4 %
github_code (search) 419 7.6 %
recrawl_hot 159 31.4 %
registry (LF) 149 43.0 %
github_topics 131 0.0 %
manifests 89 5.6 %
smithery 63 1.6 %
a2aregistry (LF) 50 78.0 %

(Numbers are live; the table updates on each crawl cycle on the State of the Agent Economy report section 2.)

Sum of seen across sources is 3,116 vs 2,603 unique agent domains, so the average agent appears in 1.20 registries. Two implications worth naming:

  1. 80 % of agents appear in exactly one registry. Federation, as a property of the deployed network, is mostly absent.
  2. The 20 % that appear in more than one registry are concentrated in the curated cluster (a2aregistry × registry × recrawl_hot). The agent that shows up in Smithery AND on Glama AND on a2aregistry is rare; the agent that shows up in three wild crawls (agentic_market + mcp_registry + github_code) is the median multi-registry case.

The matrix

Pairwise overlap, expressed as the count of agents present in both registries (rows = source A, columns = source B; symmetric, so the upper triangle is shown):

smithery glama (via lists) a2aregistry registry mcp_registry agentic_market
smithery 63 4 1 2 19 0
glama (lists) 317 3 12 29 1
a2aregistry 50 18 0 0
registry 149 6 1
mcp_registry 718 2
agentic_market 798

Notes on the methodology:

  • "glama (via lists)" reflects that the Glama public catalog is ingested through our generic lists source rather than a Glama-specific connector. The number is therefore Glama-as-found- in-the-lists-source, not a comprehensive Glama crawl. A first-party Glama connector would likely increase this row 2-3×.
  • The LF a2aregistry and LF registry overlap of 18 is partially by design — the registries cite each other and many curators submit to both. That cell is the "intended federation" data point.
  • The mcp_registry × agentic_market cell is 2 — out of 718 + 798 (= 1,516 row-impressions) we observe two domains in both. The MCP and x402 worlds barely touch.

What the matrix shows

Smithery is mostly its own ecosystem. 63 agents indexed, four appear in our generic lists ingestion (which contains Glama and several smaller catalogs), zero appear in the agentic.market corpus. Smithery's federation page advertises sync with PulseMCP and Glama, and we do see partial mirroring through lists, but the dominant Smithery slice is single-registry.

Glama (via lists) and mcp_registry overlap most: 29 agents. Both are MCP-centric, both crawl GitHub-published mcp.json manifests, both ingest the same handful of vendor-maintained MCPs (Anthropic-MCP-quickstart, the @modelcontextprotocol/server-* family). The federation that exists between Glama-style catalogs and the LF MCP registry happens through the underlying repos, not through the registry-to-registry sync.

The Linux Foundation cluster (a2aregistry + registry + recrawl_hot) is the most internally-federated subgraph. 50 + 149 = 199 cards, with 18 cross-registered between the two LF lists. This is the only place where "federation" describes the observable behaviour rather than the marketing copy.

Coinbase's agentic_market corpus is functionally siloed. 798 indexed resources, 2 appear in any other registry. The x402 payment flow is a strong-enough discovery primitive that operators register through CDP discovery and ignore the wider federation. The 0.9 % live-rate on that source — separate finding — is the long-tail fingerprint of bulk-registered resources whose endpoints rotted without a corresponding deregistration.

Why the diagonal is heavy

Three forces push agents toward single-registry residence:

  1. Different submission ergonomics. A Smithery submission walks through a card-validation UI; an a2aregistry submission expects JWS-signing and a pull request; agentic.market resources self- register through the CDP facilitator without ever creating an account anywhere. The submission funnels select different operators.
  2. Different inclusion criteria. The LF registries reject listings that don't pass live JSON-RPC probes; Smithery accepts any well-formed MCP descriptor; agentic.market accepts any URL that returns an accepts[] field. The funnels operate on different quality contracts and produce different surviving populations.
  3. Zero deduplication infrastructure. None of the public registries currently subscribe to changes from any other public registry. The federation discussions all reference a future registry-of-registries protocol — Agenstry's federation feed is one prototype, the AAIF spec draft is another — but as of May 2026 no registry imports another registry's feed in production.

The case for and against federation

The strongest argument for federation in the deployed agent ecosystem is the failure mode it would close: an enterprise compliance team that wants to know whether an agent is "registered" gets a different answer depending on which registry they consult. The fragmented status quo means ERC-8004's reputation system or any future trust scoring layer operates on different agent sub-populations depending on which feed it ingested.

The argument against is empirical: the LF cluster IS federated internally (18 cards in both, 38 % cross-rate on the smaller registry) and has done it without a protocol — through curator overlap and informal coordination. The 200-card LF subgraph might be the entire viable federation surface; everything outside is self-selecting bulk-discovery infrastructure where federation adds limited value to the operators submitting there.

The decision point is which population a future federation protocol should target. A federation-of-curated registries (LF, AAIF, selected vendors) reaches ~250 high-quality cards. A federation-of- crawlers (Agenstry, mcp.so, the long-tail) reaches the full 2,600. Both have constituencies and neither has shipped.

What we are watching

Three signals over the next quarter:

  1. Whether AGNTCY ships a federation-feed reference implementation any other registry actually imports. The spec draft is the most concrete proposal; adoption is the test.
  2. Whether the AAIF working group lands a registry-of-registries primitive in its agent-registry repository.
  3. Whether PulseMCP federation sync begins importing non-MCP catalogs. PulseMCP currently mirrors GitHub-published MCP descriptors; expanding to A2A agents would be the first cross-protocol federation.

The matrix above will be re-published quarterly on /reports/federation-overlap so the next iteration of "we just shipped federation" claims can be checked against the cross-registration data.

Sources

Cite this post

@misc{agenstry-federation-overlap-2026,
  author       = {Semler, Damiën},
  title        = {Federation overlap: counting Smithery, a2aregistry, Glama, and friends},
  howpublished = {Agenstry research blog},
  year         = {2026},
  month        = {may},
  url          = {https://agenstry.com/blog/federation-overlap-smithery-a2aregistry-glama}
}
← Back to blog Agenstry