A2A and MCP: the honest comparison

A2A and MCP: the honest comparison

The usual line is that MCP connects an agent to tools and A2A connects an agent to other agents. That is a fair first sketch.

It needs two corrections.

1. The gap has narrowed. MCP now has a Tasks extension for long-running calls. So "MCP calls are one request and one answer" is no longer a clean distinction. I read the page on 24 October 2026; check it, because it is an extension and may change.
2. The real difference is who the callee is. A tool is a piece of code with a schema, which the caller can inspect and the operator can test. An agent is opaque: the caller knows what it says it does (its card), not how. That changes what you need: a way to discover it and see what it claims, a task that can pause for a question or a credential, an identity for the user on whose behalf you call, and a message and artifact model for results that are not one JSON blob.

The Agent Card: a claim, not a fact

An agent publishes a JSON Agent Card at /.well-known/agent-card.json. The one in the example is for a venue-finding agent:

{ "name": "Venue Finder", "version": "1.0.0",
  "supportedInterfaces": [
    {"url": "https://venue.example/a2a/v1", "protocolBinding": "JSONRPC",   "protocolVersion": "1.0"},
    {"url": "https://venue.example/rest",   "protocolBinding": "HTTP+JSON", "protocolVersion": "1.0"} ],
  "capabilities": {"streaming": true, "pushNotifications": true, "extendedAgentCard": true},
  "securitySchemes": {"bearer": {"httpAuthSecurityScheme": {"scheme": "Bearer"}}},
  "skills": [{"id": "find-venue", "name": "Find a venue", "description": "...", "examples": ["..."]}] }

Three things to take from it.

Discovery. The client fetches the card, checks that required fields are present (problems() lists what is missing), and picks the first interface in the card that it can speak (the specification gives the order to the agent, not the client). My choice: a card with no usable interface is an error that says so, not a silent fall-back to a default URL.

Caching. A client that fetches the card before every call spends one request in two on something that rarely changes. With a cache and a conditional request (ETag, If-None-Match, answer 304), 20 calls cost 2 card requests, one full and one empty, against 20 full ones. The card is public and needs no token.

Trust. Anyone can publish a card that says anything. The specification offers signed cards (JWS over a canonical form of the JSON, section 8.4), and the suite checks that a changed field breaks the signature, that a key the client does not trust is refused, and that alg: none is refused. A signature proves who published the card, not that the agent is good. My code uses HS256 with a shared key, because the standard library has no public-key signatures; a real deployment uses asymmetric keys, such as the specification's ES256 example, so that the verifier cannot also forge.

What a client can do with 'trust'

I built a routing step, which picks the agent whose card best matches a request (words weighted by how rare they are across cards). Then I added a rogue agent whose card claims to do everything.

Two honest notes. My first rogue card, which only listed topics, won nothing: the router preferred the real agents. It won only after I copied the honest agents' vocabulary into its card, which costs an attacker nothing, so the result is what you should expect. And the third row is the price of the defence: refusing unsigned cards also refuses real agents whose keys you have not collected. An attacker can sign a card too, with a key of their own; the client then reports "verified: False" for that key because it is not in the trusted set.

I wrote a client from that description and ran it against the 1.0 server:

upgrade_book_card converts an old card and returns notes about what it changed or could not carry over. This is the reason the module's date is in the title page: protocols that are this new drift, and a book is a snapshot.