A2A and MCP are both open protocols for AI agents, and they are often described as rivals. They are not, according to the A2A project's own documentation: MCP connects an agent to its tools and data, and A2A connects an agent to other agents.[2] This article reads the A2A 1.0.0 specification next to the MCP 2026-07-28 specification and its Tasks extension, lays out what each defines, and ends with a guide for deciding which one a given system needs. Sections marked as our reading are interpretation, not something either specification states. For the tool side in depth, see what MCP is and how tool calling works.
The one-line distinction, from the projects themselves
The A2A documentation puts it in two sentences: "MCP is vertical. It deepens a single agent." and, used together, "MCP gives each agent depth, and A2A gives your system reach."[2] Its worked example is a repair shop. A customer talks to a Shop Manager agent over A2A. A Mechanic agent calls tools such as a vehicle diagnostic scanner and a repair manual database through MCP, and asks a Parts Supplier agent whether a part is in stock through A2A.[2]
That example shows the test that matters in practice. The scanner and the manual are capabilities you invoke. The parts supplier is a counterpart that decides how to fulfil a request, may take time, and may ask questions back.
What each specification defines
The MCP specification, dated 2026-07-28, describes a JSON-RPC 2.0 protocol between hosts (LLM applications), clients (connectors inside the host) and servers. Servers offer resources (context and data), prompts (templated messages) and tools (functions for the model to execute). Clients may offer elicitation, which lets a server request more information from the user.[4] The base protocol is described as stateless, with self-contained requests and per-request capability negotiation.[4]
A2A 1.0.0 defines a different set of objects. An Agent Card is a JSON manifest describing an agent's identity, capabilities, skills, service endpoint and authentication requirements. A Task is the "fundamental unit of work", with a unique ID and a lifecycle. Messages carry Parts (text, file references or structured data), and Artifacts are the outputs a task produces.[1] The specification defines JSON-RPC, gRPC and HTTP+JSON bindings, and treats a protobuf file as the normative data model.[1]
| Dimension | MCP (2026-07-28) | A2A (1.0.0) |
|---|---|---|
| What the counterpart is | A server exposing tools, resources and prompts | Another agent, described by an Agent Card |
| Unit of interaction | A request such as a tool call | A Task with a lifecycle, exchanged as Messages |
| Message format | JSON-RPC 2.0 | JSON-RPC, gRPC or HTTP+JSON bindings |
| Discovery | Server capability discovery between client and server | Agent Card at /.well-known/agent-card.json, registries, or direct configuration |
| Outputs | Tool results and resources | Artifacts made of Parts |
| Stated design stance | Share context and expose tools to models | Agents collaborate without exposing "internal logic, memory, or proprietary tools" |
Sources: MCP specification[4]; A2A specification and overview[1][3]. The MCP discovery cell is summarised from the Tasks page, which refers to a server/discover call.[5]
Task lifecycles now overlap
A tempting way to split the two is "MCP is for quick calls, A2A is for long jobs". With the Tasks extension that is no longer a clean rule. MCP's optional Tasks extension lets a server return a durable handle instead of blocking, so a client can poll for progress, supply input mid-flight and retrieve the result after reconnecting.[5] Both sides must opt in.[5]
| State | A2A task states | MCP Tasks statuses |
|---|---|---|
| In progress | TASK_STATE_SUBMITTED, TASK_STATE_WORKING | working |
| Needs the caller | TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED | input_required |
| Done | TASK_STATE_COMPLETED | completed |
| Ended badly | TASK_STATE_FAILED, TASK_STATE_REJECTED | failed |
| Stopped | TASK_STATE_CANCELED | cancelled |
Sources: A2A specification[1]; MCP Tasks extension[5].
Two differences are visible in the table. A2A has distinct states for authentication and for a refused request; MCP Tasks has neither. And MCP says cancellation is cooperative: the server acknowledges the intent but need not stop.[5] Our reading is that the lifecycle is no longer what separates the protocols. Who sits on the other end is.
What each leaves to you
Trust in descriptions. MCP's specification says tool behaviour descriptions, including annotations, should be treated as untrusted unless they come from a trusted server, and that hosts must obtain explicit user consent before invoking a tool. It also states that MCP itself cannot enforce these principles at the protocol level.[4]
Authorisation inside a task. A2A can move a task into an auth-required state to delegate part of the authorisation to the client. The specification then adds that agents "MUST NOT" treat that transition, by itself, as authorisation, and that the protocol does not define the scope, representation, validity or revocation of the resulting authorisation.[1] Its security schemes cover API keys, HTTP authentication, OAuth 2.0, OpenID Connect and mutual TLS, and Agent Cards may optionally be signed with JSON Web Signature.[1]
Observability. A2A's design stance is that agents collaborate without revealing internal logic or memory.[3] Our interpretation is the practical trade-off: you gain isolation, and you lose the ability to inspect why a remote agent returned what it did. Treat a remote agent's artifact as untrusted input, the same way you treat a tool result, and log the exchange on your side. The risks are covered in how agents work and how to secure them.
A decision guide (our analysis)
- One agent, several tools or data sources. Use MCP. Nothing in A2A is needed.
- A planner calling specialist prompts in one codebase. Use neither. Plain function calls are simpler, as discussed in multi-agent systems: when subagents help and when they hurt.
- Your agent must delegate to another team's or vendor's agent. Use A2A, and publish or consume an Agent Card. Check that the counterpart supports the protocol version you target; A2A uses an
A2A-Versionheader and servers returnVersionNotSupportedErrorfor versions they do not support.[1] - A tool that takes minutes. Use MCP Tasks if both your client and server support the extension; the specification says host support varies.[5] A2A is not required just because a job is slow.
- Both parts exist. Use both, with MCP inside each agent and A2A between them, as in the repair-shop example.[2]
What is still uncertain
Neither specification says how many production systems use the other protocol alongside it, so we make no adoption claim. The A2A site attributes the project to the Linux Foundation and states that it is joining the Agentic AI Foundation; we did not read the foundation's own announcement in this review, so details of governance are left out.[3] Both specifications are moving: the MCP page we read is the "latest" alias, and A2A's page lists versions 0.1.0, 0.2.6, 0.3.0 and 1.0.0.[1] Check the versions your libraries implement before relying on any behaviour described here. We ran no implementation of either protocol for this article.
