--- title: "Federation overlap: counting Smithery, a2aregistry, Glama, and friends" date: 2026-05-17 summary: "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." slug: federation-overlap-smithery-a2aregistry-glama author: "Damiën Semler" hero_glyph: grid kind: research --- The agent ecosystem currently runs at least six public registries claiming federation as a value proposition: [Smithery](https://smithery.ai), [Glama](https://glama.ai), [PulseMCP](https://www.pulsemcp.com), [the AAIF Agent Registry](https://github.com/AAIF-org/agent-registry), [the Linux Foundation a2aregistry](https://github.com/Linux-Foundation/a2aregistry), and [the Linux Foundation registry](https://github.com/Linux-Foundation/agent-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](https://mcp.so/federation), [the AGNTCY federation proposal](https://github.com/agntcy/spec), 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](https://agenstry.com/reports/state-of-agent-economy) 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](https://smithery.ai/federation) 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](https://agenstry.com/api/feed/all.jsonl.gz) 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](https://eips.ethereum.org/EIPS/eip-8004) 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](https://github.com/agntcy/spec) 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](https://github.com/AAIF-org/agent-registry).** 3. **Whether [PulseMCP federation sync](https://www.pulsemcp.com/federation) 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](https://agenstry.com/reports/state-of-agent-economy) so the next iteration of "we just shipped federation" claims can be checked against the cross-registration data. ## Sources - [Smithery.ai catalog](https://smithery.ai) — Smithery, live. - [Glama.ai catalog](https://glama.ai) — Glama, live. - [PulseMCP](https://www.pulsemcp.com) — PulseMCP, live. - [Linux Foundation a2aregistry](https://github.com/Linux-Foundation/a2aregistry) — LF AI & Data, retrieved 2026-05. - [Linux Foundation agent-registry](https://github.com/Linux-Foundation/agent-registry) — LF AI & Data, retrieved 2026-05. - [AAIF agent-registry working group](https://github.com/AAIF-org/agent-registry) — AAIF, retrieved 2026-05. - [AGNTCY federation specification](https://github.com/agntcy/spec) — AGNTCY, retrieved 2026-05. - [mcp.so federation page](https://mcp.so/federation) — mcp.so, live. - [Coinbase CDP Discovery API](https://docs.cdp.coinbase.com/x402/docs/discovery) — Coinbase, retrieved 2026-05. - [ERC-8004 Trustless Agents](https://eips.ethereum.org/EIPS/eip-8004) — Ethereum Improvement Proposals, retrieved 2026-05. - [Agenstry federation feed](https://agenstry.com/api/feed/all.jsonl.gz) — Agenstry, live. - [State of the Agent Economy report](https://agenstry.com/reports/state-of-agent-economy) — Agenstry, live. ## Cite this post ```bibtex @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} } ```