A2A vs MCP: Which Protocol Does Which Job

A2A and MCP are complementary. That is true, and it does not help anyone decide which one a given call should use.

The useful question is narrower. When your agent needs something done, who should decide how it gets done? If the answer is your own agent, you want MCP. If it is someone else's agent, you want A2A. Everything else in the comparison follows from that one split.

This post covers what each protocol standardises, the test for choosing between them, and the mistakes that show up when teams pick the wrong one.

The one-line difference

MCP connects an agent to tools and data. The agent reads the list of available tools, decides which to call and with what arguments, and gets a result back. The server does what it is told. All the reasoning stays with the caller.

A2A connects an agent to another agent. The calling agent describes a task. The remote agent decides how to do it, may take minutes or hours, may come back asking for more input, and returns finished output. The caller never sees the remote agent's prompts, tools or memory.

MCP is a function call with a contract. A2A is handing work to a colleague.

What MCP standardises

MCP came out of Anthropic in November 2024 and was donated to the Agentic AI Foundation, a directed fund under the Linux Foundation, in December 2025. The revision in force today is the one dated 2026-07-28, published at the end of July.

The model is simple. A host is the application the user works in. Inside it, a client holds a connection to each server, and the two sides exchange JSON-RPC 2.0 messages. A server offers three kinds of thing:

• •Tools, functions the model decides to call. The spec describes them as model-controlled.
• •Resources, context and data the application chooses to load.
• •Prompts, templated messages and workflows the user picks.

A tool is described by a name, a plain-language description the model reads, and a JSON Schema for its input:

{
  "name": "get_invoice",
  "description": "Fetch one supplier invoice by its ID. Read-only.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string" }
    },
    "required": ["invoice_id"]
  },
  "annotations": { "readOnlyHint": true }
}

There are two standard transports. stdio runs the server as a local subprocess of the client. Streamable HTTP runs it as a remote endpoint. For HTTP servers the spec builds authorization on OAuth 2.1: the server acts as an OAuth resource server, publishes its metadata under RFC 9728, and clients must name the server they want a token for, under RFC 8707, so a token minted for one server cannot be replayed against another. Local stdio servers take their credentials from the environment instead.

The July revision changed the plumbing in ways worth knowing before you build. MCP is now stateless: there is no initialisation handshake and no protocol session, and every request carries its own version and capabilities. When a server needs more information mid-request, it returns an "input required" result and the client retries with the answers. Long-running work moved into an official tasks extension. Three older client features, Roots, Sampling and Logging, are deprecated.

None of that changes the shape of the contract. The caller's agent plans. The server executes.

What A2A standardises

Google launched A2A in April 2025, describing it as complementary to MCP, and handed it to the Linux Foundation that June. Version 1.0, the first stable specification, followed in March 2026, with a bug-fix release, 1.0.1, in May. On 17 August the Agentic AI Foundation announced that A2A is joining it as a hosted project, which will put both protocols under the same roof.

A2A starts from a different premise, which its specification calls opaque execution: agents collaborate "based on declared capabilities and exchanged information, without needing to share their internal thoughts, plans, or tool implementations."

The pieces that follow from that:

• •Agent Card. A JSON document at /.well-known/agent-card.json describing the agent's identity, skills, endpoint and authentication requirements. Cards may be signed with JSON Web Signature. Our guide to A2A agent cards walks through one field by field.
• •Task. The unit of work. Tasks are stateful and move through a lifecycle: submitted, working, input required, auth required, then completed, failed, canceled or rejected.
• •Message, Part and Artifact. Messages are turns between the client and the remote agent. Parts carry text, file references or structured data. Artifacts are the outputs the task produces.
• •Bindings. JSON-RPC 2.0 over HTTP, gRPC, or plain HTTP with JSON, with Server-Sent Events for streaming and webhook push notifications for work that outlives a connection.
• •Authentication. The card declares the schemes a caller must use, and the caller must authenticate with one of them.

The A2A documentation puts the distinction in one line: "A2A focuses on agents partnering on tasks, whereas MCP focuses on agents using capabilities."

The test: who owns the reasoning?

Put the two side by side and the choice usually makes itself.

Three questions settle most cases:

1. Is the work deterministic once the inputs are known? Looking up an invoice, creating a ticket, querying a warehouse. That is a tool. Use MCP.
2. Does the work need its own judgement, its own tools and possibly a human of its own? Reviewing a contract against a policy, running a multi-step research job, handling a refund dispute end to end. That is a task for another agent. Use A2A.
3. Who is accountable if it goes wrong? If your team owns the outcome, keep the reasoning in your agent and expose the systems as tools. If another team or company owns how the work is done, give them a task and let them answer for it.

Where teams get it wrong

Wrapping a whole agent as an MCP tool

It is tempting, because MCP is the protocol everyone already has wired in. You expose another team's agent as a single tool called something like run_research and call it from your main agent.

The July revision makes this more workable than it was: the tasks extension covers jobs that run for minutes, and the input-required pattern lets the server ask a question. What it does not change is that a tool is a function signature. Your agent sees a name, a description and an input schema. It cannot see the other agent's skills, its authentication requirements or what state its work is in, so it cannot reason about any of them. And when the result is wrong, the accountability is muddled: your agent called a function, but someone else's judgement produced the answer.

If the thing on the other end makes its own decisions, give it a task, not a tool.

Using A2A for what is really a lookup

The opposite mistake costs more to build. If the remote side does one deterministic thing, wrapping it in a task lifecycle, an agent card and an asynchronous status model adds moving parts and latency for no gain. A tool, or a plain API with a good OpenAPI description, is the right shape.

Treating either protocol as a security boundary

Neither protocol decides what your agent is allowed to do. MCP gives you a way to authenticate a client to a server. A2A lets an agent card declare how callers should authenticate. Both are transport and identity plumbing.

What an agent may read, write or delete is still your policy, enforced by the credentials each server holds and the scopes each token carries. An agent with a broad token is a broad risk whichever protocol it speaks. We covered how quickly that access sprawls in The 144:1 Problem.

Using both together

In practice the two layer cleanly. A typical shape for a mid-sized company looks like this:

• •Each internal system the agents need, such as the ERP, the CRM, the ticketing tool and the document store, gets an MCP server with its own narrowly scoped credentials.
• •Each agent that does a distinct job uses those MCP servers as its tools.
• •Where one agent needs another agent's judgement, especially across a team or company boundary, it calls that agent over A2A, discovering it through its agent card.

The A2A specification describes exactly this layering: a server agent receives an A2A task and "might use MCP to interact with several underlying tools, APIs, or data sources" to complete it. Your agent never needs to know which tools the other agent used. It needs the result, the state of the task and someone to answer for it.

The design question is not which protocol to adopt. It is where the boundaries of judgement sit in your workflow. Draw those first, and the protocol for each line falls out of the drawing.

What to decide this quarter

For a mid-market team, we would take it in this order.

1. Start with MCP for your own systems. Inventory the systems an agent would need to read or change, and wrap the first two or three as MCP servers with read-only scopes. This is where the first useful work happens, and it is the groundwork for AI tools over your own data.
2. Add write access deliberately. Separate read tools from write tools, put a human confirmation in front of anything destructive, and log every call.
3. Adopt A2A when a second agent appears that you do not own. A vendor's agent, a partner's, or another department's. Publish an agent card for any agent you expose, and read the cards of the ones you call.

If you are building the agent layer itself, our AI development work starts with exactly this map: which systems, which agents, and where the lines between them run.

Working out which of your systems an agent should reach first, and through which protocol? Contact us and we will help you draw the map before anyone writes a server.