MCP and A2A
MCP is how a model client reaches tools and data: it calls a server, the server does something, the result comes back inside the client's own reasoning. A2A is how two agents deal with each other as peers: one delegates a task, the other owns it and reports. Connect publishes an MCP server and an A2A agent card, and choosing wrongly produces an integration that fights its own shape.
The difference in one sentence each#
- MCP
- *Give my model a capability.* The client stays in charge of the reasoning; the server supplies tools, resources and prompts, and returns results into the client's context.
- A2A
- *Give this job to somebody else.* The remote agent does its own reasoning, holds the task, and reports on it. The caller does not micro-manage the steps.
The clean test is where the thinking happens. If your model should think and Connect should fetch or act, that is MCP. If Connect should think and your system wants the outcome, that is A2A.
The protocols, as published#
| MCP | A2A | |
|---|---|---|
| Version used here | 2026-07-28 | 1.0.0 |
| Discovery | The client is configured with the endpoint | /.well-known/agent-card.json |
| Transport | Streamable HTTP — one endpoint, POST only | HTTP, per the A2A specification |
| Shape of a call | A tool invocation with typed arguments | A task handed over, with its own lifecycle |
| Who reasons | The calling model | The receiving agent |
Two details of this MCP revision catch people out. Protocol-level sessions and the standalone GET stream were removed: Mcp-Session-Id and Last-Event-ID are ignored, and GET or DELETE answers 405. And a server must validate Origin and answer 403 when it is present and invalid — so a browser-originating call that works against a permissive server may be refused here by design.
POST /mcp HTTP/1.1
Host: connectbyjbrh.com
MCP-Protocol-Version: 2026-07-28
Content-Type: application/json
{"jsonrpc":"2.0","id":1,"method":"tools/list"}What goes wrong when they are confused#
- Treating the agent card as a tool list. It describes an agent and how to reach it. It is not an inventory of callable tools, and reading it as one produces a client that never finds anything to call.
- Expecting MCP to hold a long-running task. Sessions were removed from this revision; a tool call is a call. Anything with a lifecycle belongs on the A2A side or on a job you poll.
- Delegating over MCP. You can express *do this whole thing* as a tool, but you then own the orchestration, the retries and the partial failures — which is what the A2A task lifecycle exists to carry.
- Calling A2A per fact. A task handover per lookup is expensive and slow. Reads belong on tools.
- Assuming either one authenticates by itself. Anything that is not public requires authentication in both directions; see MCP authentication.
Choosing, in practice#
Ask whether your side or Connect's side should decide what to do next.
Result That single answer picks the protocol, and picking it first saves rewriting the integration later.
For a model that needs Connect's records mid-reasoning — a support copilot that wants a customer's history — use MCP.
Result The result lands in your model's context and your prompt keeps control.
For a system that wants an outcome — *handle this enquiry* — use A2A.
Result Connect owns the work and reports; you are not simulating an agent loop from outside.
Where you need both, use both. They are not alternatives.
Result Reads over tools, handovers over tasks — which is how the two surfaces are meant to be used together.
Questions#
Does Connect support both?
Yes. The MCP server and the A2A agent card are both in production, the card at the well-known URI. Which you should use is a question about your architecture rather than about availability.
Why does my MCP client's GET request fail?
Because this revision removed the standalone GET stream. One endpoint, POST only; GET and DELETE answer 405. A client written against an older revision will need its transport updated rather than its credentials checked.
Can another company's agent talk to my workspace over A2A?
Only with authentication that resolves to your workspace. Discovery is public — the agent card says what Connect is and how to reach it — but reaching your data is not, and the same three isolation layers apply as to any other path.