APIs.io now has a section for A2A Agent Cards, and I want to talk about what building it taught us, because the interesting part is not the section — it is what we found when we went looking. The Agent2Agent (A2A) Protocol, now at 1.0.0 and governed by the Linux Foundation after being contributed by Google, defines an Agent Card: a JSON manifest an agent publishes at /.well-known/agent-card.json advertising its identity, its capabilities, its skills, its endpoint, and how you authenticate against it. It is the DNS-adjacent, RFC 8615 shaped discovery layer for agents, and A2A’s own documentation names a curated registry as one of the three legitimate ways cards should be found. A catalog holding agent cards, queryable by skill and tag and provider, is a thing the specification explicitly asks someone to build. So we built it. And then the data told us something I did not expect.
The probe was straightforward and deliberately dumb. Every absolute host that appears anywhere in the APIs.io catalog — website, developer portal, MCP server, documentation, API reference — got pulled out and deduplicated, which produced 22,341 unique hosts. Of those, 20,185 answered. Each one was fetched at /.well-known/agent-card.json and, because the path changed at A2A 0.3, also at the legacy /.well-known/agent.json. Sixty-five providers serve a card. That is 0.29 percent of the reachable web surface of the entire API industry as APIs.io has profiled it. Adoption of agent discovery, measured honestly rather than by counting conference talks, is a rounding error.
That number alone would have made a fine post. But the second finding is the one that changed how the section works. Of the 65 providers serving a card, only 10 pass every structural check in the A2A 1.0.0 AgentCard object. Fourteen more are near-conformant — they miss something soft like defaultInputModes but get the shape right. The remaining 41 fail a hard structural requirement. They ship capabilities as an array where the spec defines it as an object. They ship supportedInterfaces where the spec says additionalInterfaces. Forty of the 65 declare no protocolVersion at all, which means a client cannot tell what it is parsing before it parses it. Twelve ship skills as something other than an array. Eight have no url. One has no name.
And fifteen of the 65 — twenty-three percent — are still sitting at /.well-known/agent.json, the pre-0.3 path, where a spec-compliant A2A 1.0.0 client will simply never look. Those providers have published a card that, as far as the current protocol is concerned, does not exist. If we had only probed the canonical path we would have missed almost a quarter of the population and reported a cleaner, smaller, wronger number.
This is why the APIs.io A2A section grades rather than counts. A boolean a2a: true field would have told you there are 65 A2A adopters in the catalog. That statement is false in the way that matters: 41 of them have published something an A2A client cannot reliably consume. Counting would have produced a headline — “A2A adoption reaches 65 providers” — that every vendor deck would happily reuse and that no integration would survive. So every card on the section carries a grade, the deviations are enumerated by name on the provider’s page, and the legacy path is flagged. If you own one of these cards you can see exactly which field to fix. That is the difference between a catalog and a leaderboard.
I want to be fair to the 41, because “flavored” is not the same as “sloppy.” Some of these are among the better-known names in the space — Cloudflare, Pinecone, Razorpay, Monday, Apideck, QuickNode, Attio, Speakeasy, Gravitee — and Forter publishes 25 skills on its card, more than anyone else in the catalog, while still failing a structural check. These are teams that read about agent cards, understood the intent, and shipped one. Nobody told them the shape had changed at 0.3, or that capabilities was an object, because there was no validator in their pipeline and no registry looking over their shoulder. This is the ordinary, entirely predictable outcome of a specification that moved fast, changed its well-known path, and reached practitioners through blog posts rather than through tooling. The failure here is not the providers. It is the total absence of a feedback loop between publishing a card and finding out whether it works.
The third finding is the one I keep chewing on, and it is more consequential than the conformance numbers. The Agent Card is quietly decoupling from A2A. Look at what the conformant ten actually point at. Pydantic’s card declares preferredTransport: MCP and resolves to https://logfire.pydantic.dev/mcp. Phish.in — yes, the Phish live audio archive, publishing a cleaner agent card than most of the enterprise catalog — points at an MCP endpoint too, with 16 skills declared. 1inch, Buddy, and Superset run JSON-RPC but describe MCP servers behind it. Providers are reaching for the Agent Card not because they intend to speak A2A to other agents, but because it is the only widely-known machine-readable way to say here is my agent surface, here is what it can do, here is where to authenticate. They want the manifest. The protocol is incidental.
That is a meaningful signal about where discovery is heading. The industry needs an agent-facing equivalent of what OpenAPI did for HTTP APIs — a document at a predictable location that describes capability rather than just endpoints — and A2A’s Agent Card is currently the closest thing available, so people are using it for that even when they are not using A2A. Whether the A2A community embraces that role or fights it will determine whether the format survives its own success. My read is that the manifest is the durable artifact and the transport is the negotiable part, which is why the APIs.io section catalogs agent discovery with A2A conformance as a grade inside it, rather than naming anything a2a_support.
There is one more property of this artifact that makes it unusual in our work, and it is worth stating plainly because it cuts against how the rest of the catalog gets built. An Agent Card cannot be derived. Most of what APIs.io profiles can be reconstructed when a provider does not publish it — an OpenAPI can be built from documentation, authentication patterns can be read off a developer portal, rate limits can be pulled from pricing pages. An Agent Card cannot. It is served from the provider’s own host at a well-known path, or it does not exist. There is no generating a plausible one, and doing so would destroy the exact property that makes it worth anything. If a provider has a card in the APIs.io catalog, that provider put it there. That is why the Agent Card dimension in the Kin Score is search-only and carries real weight — it is one of the very few signals in agent readiness that is impossible to fake and impossible to backfill.
Which brings me to the honest close. Sixty-five out of 22,341, and ten of those actually conformant, is not an adoption story — it is a starting line. The gap between how much the industry talks about agent interoperability and how many companies have spent the twenty minutes it takes to publish a valid JSON file at a well-known path is enormous, and that gap is the whole point of putting the section up. If you are one of the 41, the deviations are named on your page and most of them are a one-line fix. If you are one of the fifteen on the legacy path, serve the same document at /.well-known/agent-card.json and you are discoverable again. And if you are one of the 22,276 with nothing there at all, the bar for entry is far lower than the conversation around agents would lead you to believe. The catalog is at apis.io/a2a, it re-probes on every enrichment run, and the grades will move as the fixes land.
