A2A — the Agent2Agent protocol

What A2A is for, and what MCP is for#

The two protocols are often presented as rivals, which misreads both. MCP connects a *client* to *capabilities*: a model client holds the connection, reads a list of tools and calls them with arguments it constructs. A2A connects an *agent* to *another agent*: the caller does not know the callee's internals, does not construct a function call, and asks a question in words that the callee's own reasoning answers.

A useful test: if you already know which function you want, you want MCP. If you have a question and are looking for someone able to answer it, you want A2A. Connect offers both, over the same documentation corpus, so the answers cannot diverge.

The exchange, end to end#

1. Fetch /.well-known/agent-card.json from the domain you are interested in.

   Result A JSON document naming the agent, its protocol version, the URL to send messages to, its declared capabilities and its skills.

2. POST a JSON-RPC message/send to the URL the card gives, with a message whose parts contain a text part.

   Result A result of kind message, role agent, carrying reply parts and a contextId you can quote on a follow-up.

3. Name a skillId from the card if you know which skill you want.

   Result That skill answers. Omit it and Connect chooses from the shape of the question, because an agent that arrived via a well-known URI often has not read the skill list.

POST /a2a HTTP/1.1
Host: connectbyjbrh.com
Content-Type: application/json

{"jsonrpc":"2.0","id":"7","method":"message/send",
 "params":{"skillId":"describe-capability",
           "message":{"parts":[{"kind":"text",
                                "text":"Can Connect record a phone call?"}]}}}

A reply carries a text part and, where there is something structured worth handing to a program, a data part beside it — the page URL, the status word, the other candidate pages. metadata names the skill that answered and the documentation root the answer came from, so a caller can audit which surface produced what.

Does Connect use A2A?#

Yes, as a server, in production. Protocol version 1.0.0; the card lives at /.well-known/agent-card.json and the endpoint is POST /a2a. Five skills are published and every one reads the generated public documentation: explain-connect answers a question from the closest page, search-connect-docs returns matching pages, describe-capability reports the status vocabulary and the status of the nearest documented capability, explain-workflow returns an end-to-end workflow page, and explain-integration answers from the protocol, developer and technology references.

There is no authenticated extended card. The card declares supportsAuthenticatedExtendedCard: false, and a call to agent/getAuthenticatedExtendedCard is answered with -32004 and a sentence saying the public card is the whole advertised surface. Adding a private one would be a real decision about exposing workspace capability to other agents, and pretending it exists would be worse than not having it.

Streaming is not offered either. The card declares streaming: false and message/stream returns -32004 pointing at message/send. Push notifications are likewise declared false. Every skill answers from generated files, so there is nothing to stream.

Connect is not an A2A *client*: it does not go out and call other agents' cards.

Limits and refusals#

One thing worth planning for: this endpoint answers about the public documentation, so a question about a specific business's mail, calls or customers has no useful answer here and will come back as documentation about that subject. That is not a failure to be retried — it is the boundary of the surface.

Questions#

Related#

• The A2A Agent Card
• A2A agent discovery
• Model Context Protocol
• Interoperating over A2A
• JSON-RPC 2.0