N cards, N models, N governing bodies. What could possibly go wrong?
That was my first thought, too. So let's look at it properly.
The business card you hand over before the meeting
Before a meeting, you hand someone a business card. It doesn't do the work. It tells them who you are, what you do, and how to reach you, so the conversation can start in the right place.
AI agents have the same thing now. The A2A project describes its Agent Card in exactly those words: "It acts as a digital business card."
An agent's card is a small public file. It says who the agent is, what it can do, which version it runs, and where to reach it. Crucially, another program can read it before connecting, so it can decide whether to connect at all.
Agents have them. And, since 6 October, so do MCP servers.
A2A has had Agent Cards for a while. On 6 October 2026 MCP caught up: Server Cards (SEP-2127) went Final.
An MCP Server Card carries a server's name, version, description and the address of its endpoint. It deliberately leaves out the tools themselves, because those can change from user to user and from minute to minute. The card is the introduction; the connection is the conversation.
And then there are the others: the MCP Registry's own server listing, AI Catalog entries that point at cards, and identity files that projects keep about themselves. That's the "N cards".
The case for "yes, it's a house of cards"
I wanted to know how many servers actually carry a card, so I checked.
I took a sample of the official MCP Registry: about 50 servers with a public address. I asked each one for its card at the address the spec reserves for it.
One had one. And it was a good one: small and tidy, listed in the site's own AI Catalog, with an AGENTS.md for agents to read.
That's not a scandal; the spec had only been Final for a few days. But one in fifty shows the gap.
It gets more interesting. A card is advisory. The spec says so plainly: clients shouldn't treat a card as the truth, but check it against the live connection. A card can drift out of date, overstate what a server supports, or quietly break the small technical rules that let a browser read it at all.
So I pointed a checker at one of my own live servers, one I'd built and was rather pleased with. It failed two of the spec's required checks. Two headers a browser needs, to read the card and to ask politely whether it had changed, were both missing.
Then I checked the one good card I'd found. It failed one of the same checks: a browser still couldn't ask politely whether it had changed.
N cards, N models, N governing bodies, and cards that looked fine but weren't. That's the house of cards, right there.
The case for "no"
Here's what changes the answer.
N governing bodies is shrinking. MCP and A2A, the two big agent protocols, now live under one roof: the Agentic AI Foundation, at the Linux Foundation, alongside goose and AGENTS.md. And the roof keeps growing: agentgateway joined in June, A2A in August, and Agent Router (formerly Envoy AI Gateway) in September. The protocols, and the gateways that route traffic between them, now answer to the same neutral home.
The cards are being linked, by both camps. AI Catalog, currently maintained by the Linux Foundation, is one format for listing cards across protocols. A catalog can point at an MCP Server Card, an A2A Agent Card, or anything else, by type. Its technical steering committee has four seats: two nominated by MCP's core maintainers, two by A2A's steering committee. The bridge is literally built from both sides.
The rules are written down, and they're checkable. SEP-2127 says where a card lives, what it must contain, which headers it must send, and what it must never include (credentials, private addresses). Rules you can check are rules you can fix.
And that's exactly what happened. I found the two failures because the check exists. I fixed them and redeployed the same day. Checked again: no required failures.
A house of cards falls over when you touch it. This one got stronger.
A business card you can actually see
There's one more piece. Agent Cards and Server Cards are written for machines, in JSON. But a business card is meant to be handed to a person.
So I print one as a business card. On the front: the name, a title, and a one-liner, the way you'd read a real one. Flip it over and the back holds the detail: the full identity, the project's instructions for agents, what it remembers, and how machines find it.
Same facts, two readers: one for machines, one for humans.
Where it's heading
Three things are worth watching:
- Verified cards. If a card is advisory, the next step is a card that someone has checked, with the check visible. AI Catalog is already working on how independent assessors can sign what they've checked.
- Cards that don't drift. The spec asks that a card never contradict the server it describes. Tooling that keeps the two in step makes that the default rather than a hope.
- Business cards for people, too. A business card works for a person as well as an agent. The title tells you which.
So: is it a house of cards?
It sounds like one: N cards, N models, N governing bodies. But the bodies are converging, the cards are being linked by the people who write the protocols, and the rules are specific enough to check.
The real risk isn't the number of cards. It's cards that nobody checks.
Check yours.
More
-
See a project's business card:
npx -y mcp-context-card card, run in any project folder. mcp-context-card is open source (MIT), an MCP server for a project's context, memory and identity. It serves a Server Card that passes SEP-2127. - The specs: MCP Server Cards (SEP-2127) · A2A Agent Card · AI Catalog
Top comments (0)