We index 226 A2A Agent Cards across the APIs.io network — every provider we can find serving a machine-readable agent manifest at /.well-known/agent-card.json. We grade each one against the A2A 1.0.0 specification rather than counting it, because a boolean “has an agent card” would report 226 adopters of a specification that a quarter of them are not following. 160 are conformant. Ten are near-conformant. Fifty-six are not, and what keeps them out is smaller than anyone would guess.
Fifty-three of the fifty-six are missing protocolVersion. One field. Nineteen ship capabilities as an array where the spec defines an object, fourteen ship skills as something other than an array, and twenty fail more than one check — but the single most common reason a published agent card fails to qualify as an agent card is a version string nobody added.
That is worth sitting with, because it is not a story about carelessness. These are companies that decided to publish an agent manifest, picked the canonical RFC 8615 path, wrote real skill definitions, and shipped. The card exists because somebody cared. It falls short on a field whose absence is invisible until a strict client tries to read it and has to guess which version of the protocol it is talking to.
What we do with a card that falls short
Nothing punitive. We grade it, we publish the grade with the fetch date and the HTTP status behind it, and we name the deviation. The provider never asked to be listed — they published a document in public and we found it — so the honest thing is to report what the document says, not to editorialize about it.
That rule cost us recently. Until this week, 52 of those 226 grades were wrong, and 46 were wrong in the direction that made a provider look worse than their card deserved. The grades had been hand-authored by the enrichment pass that harvested each card, and those passes applied judgment the rubric does not contain — penalizing supportedInterfaces instead of additionalInterfaces, or an interface pointing at documentation rather than a callable endpoint. Real observations, every one. None of them is a hard check. Twenty-two cards were publicly labelled “Flavored” — which we define to readers as an agent card in spirit, not in schema — while passing every check the rubric states.
The grade is now computed from the card itself by the same function in every place that grades one, and the hand-written observations are kept as evidence beside it rather than deciding it. If a page says your card fails, it fails a named check you can run yourself.
The registry these cards can now join
Everything above describes the supply side: what API providers publish. This week we opened the other half — a registry of agents that consume APIs. Most of the agents that matter to an API provider will never appear anywhere else in this catalog, because they publish no API at all. They call yours.
Registration is performed by the agent, not by a person on its behalf:
curl -X POST https://apis.io/api/v1/agents/register \
-H 'content-type: application/json' \
-d '{"card_url": "https://your-host/.well-known/agent-card.json"}'
No account, no API key, no form. There is no credential because an agent that has to get one from a human before it can register itself is exactly the onboarding friction our own Agent Readiness rubric marks providers down for. What replaces the key is the card: you must already be serving a conformant one on a host you control, which is a bar no spammer clears for free and the same bar every card in the index is held to.
If your card is not conformant yet, the endpoint refuses it and tells you which of the three checks failed, rather than saying no:
{
"error": "card_not_conformant",
"deviations": ["no-protocolVersion"],
"checks": {
"capabilities-is-object": true,
"protocolVersion-present": false,
"skills-is-array": true
}
}
Fix the field it names and call again. The registration is yours as soon as the card is right.
What listing actually means
Your card gets re-fetched nightly, so your entry states what you are serving now rather than what you served on the day you registered. If it stops resolving we record the failed check and say when it last worked — and a registration is only called dead after three consecutive failures, because one night of DNS trouble is not a withdrawal. If you withdraw, the record stays marked withdrawn rather than disappearing. You served it once, and deleting that would turn a registry into a snapshot.
We do not write cards on anyone’s behalf. An agent card cannot be derived — it is served from a host its operator controls, over their own TLS, or it does not exist. That is the one agent surface in this entire catalog that cannot be manufactured for you, which is exactly why it is the one we ask for.