A2A vs MCP in 2026: when agents should talk to agents instead of calling tools

Two protocols show up in almost every 2026 agent design conversation: MCP and A2A. They are often presented as rivals, which is the first mistake. MCP and Agent2Agent solve different problems at different layers, and a production system frequently needs both. The useful question is not which one to standardize on, but which direction a given integration actually points: toward a tool you call, or toward a peer you delegate to.

The one-question test

Ask one thing about the system on the other side of the connection: does it own a goal and make its own decisions, or does it expose a capability and wait to be invoked?

If it is a capability (search the catalog, run a query, read a file, create an invoice), that is a tool. The calling agent stays the decision maker. This is MCP territory.
If it is an autonomous worker that accepts a goal, possibly plans multiple steps, may ask clarifying questions, and reports back later, that is a peer agent. This is A2A territory.

A payment API wrapped as a tool refunds an order when told to. A billing agent wrapped for A2A might receive "sort out last quarter's failed renewals" and decide how many refunds, retries, and emails that requires. Only the second one deserves to be an agent.

What each protocol actually defines

Dimension	MCP	A2A
Relationship	One client agent to a tool/data server	Peer agent to peer agent
Interaction unit	Tool call, resource read, prompt	Message and long-lived task
Discovery	Configured server endpoint	Public Agent Card at a well-known URL
Lifetime	Usually a single request/response	A task state machine with status over time
Who decides	The calling agent	Each agent decides how to fulfill its task
Typical transports	stdio, streamable HTTP	JSON-RPC, HTTP+JSON (REST), native gRPC
Identity	A server exposing tools	A named agent advertising skills

MCP is deliberately tool-centric. A server lists tools, resources, and prompts; the connected model decides which to call and how to compose them. The server has no opinion about the user's goal. A2A is delegation-centric: you address a named agent, hand it a message, and receive a task that moves through states such as working, input-required, completed, or failed, potentially over a stream.

Discovery is the tell

The two protocols reveal the boundary in how you find them.

An MCP server is something you configure. You give an agent a server command or URL and credentials; there is no assumption that a random client can discover it.

An A2A agent publishes an Agent Card at a well-known path so other agents can find and understand it without a private introduction:

curl https://billing-agent.example.com/.well-known/agent-card.json

The card names the agent, lists its skills, and advertises the interface bindings it speaks. A single card can expose JSON-RPC, REST (HTTP+JSON), and gRPC endpoints for the same agent:

{
  "name": "Billing Agent",
  "description": "Handles renewals, refunds, and invoice disputes",
  "version": "1.0.0",
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "reconcile-renewals",
      "name": "Reconcile renewals",
      "description": "Retry and refund failed subscription renewals for a period",
      "tags": ["billing", "subscriptions"]
    }
  ],
  "supportedInterfaces": [
    { "protocolVersion": "1.0", "protocolBinding": "JSONRPC", "url": "https://billing-agent.example.com/rpc" },
    { "protocolVersion": "1.0", "protocolBinding": "HTTP+JSON", "url": "https://billing-agent.example.com/rest" },
    { "protocolVersion": "1.0", "protocolBinding": "GRPC", "url": "https://billing-agent.example.com:50051/" }
  ]
}

A client fetches that one public document, reads the skills and bindings, and chooses how to talk. There is no equivalent public "tool resume" in MCP because MCP assumes the caller already knows the server.

Tasks are stateful; tool calls are not

The deeper difference is the lifecycle. An MCP tool call is conceptually immediate: invoke, get a result (or a stream of output), done. A2A models work that outlives a single request. You send a message and receive a task, then you can query it, subscribe to updates, cancel it, and, in 1.0, configure push notifications.

A minimal A2A 1.0 JSON-RPC message looks like this:

{
  "jsonrpc": "2.0",
  "id": "a17c2e10-7b6e-4f9a-9d3a-2b8c4e6f1a00",
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "msg-0001",
      "role": "ROLE_USER",
      "parts": [{ "text": "Reconcile failed renewals for Q3 and report the totals" }]
    }
  }
}

The response is not just a value; it is a task with an identifier and a state. Streaming methods such as SendStreamingMessage and SubscribeToTask push progress events until the task reaches a terminal state. That is the machinery you need when the worker on the other side is genuinely doing multi-step work, and it is pure overhead when it is just adding two numbers.

Versioning is not optional to know about

A2A 1.0 and the earlier 0.3 line are not wire compatible. Method names changed (SendMessage versus message/send), message parts changed shape (1.0 uses { "text": "..." } with roles like ROLE_USER; 0.3 uses { "kind": "text", "text": "..." } with user), and the transport story differs: 0.3 is JSON-RPC, while 1.0 adds REST and native gRPC bindings. A client must read the card's protocolVersion and speak that dialect rather than assuming one. MCP has its own version evolution, but the agent-to-agent surface makes mismatches louder because discovery hands you the version explicitly.

Where they compose

The mature pattern is a stack, not a choice:

A specialist A2A agent receives a delegated goal.
Internally, that agent uses MCP tools and ordinary HTTP APIs to do the work.
It reports task state back to the requesting agent over A2A.

In that topology A2A is the inter-team protocol between autonomous units, and MCP is the intra-team protocol an agent uses to reach capabilities. Forcing a stateless lookup into A2A buys you a task state machine you will never advance. Forcing a goal-owning, multi-step worker into MCP leaves the caller responsible for orchestration that should have lived behind the worker's boundary.

A practical decision checklist

Use MCP when the other side is a known capability with no goal of its own, the work is a single call or a direct stream, and your agent should stay the orchestrator.

Use A2A when the other side is a distinct agent with its own planning and skills, work spans multiple steps or time, you need public discovery and a capability resume, or you need task status, streaming updates, and cancellation as first-class concepts.

Use both when autonomous agents must collaborate but each still reaches tools underneath.

The temptation to over-agent is real: wrapping every internal API in an Agent Card produces a network of peers that own no goals, which is harder to debug than the tools it replaced. Start with tools, and promote something to an agent only when a real, delegable goal exists.

If you want to see the two protocols side by side in one place, the Powerduck workspace lets you design and debug both MCP endpoints and A2A agents (including Agent Card discovery, signature verification, and JSON-RPC, REST, and gRPC bindings) against the same local API spec; the online demo shows the spec-driven loop, and the tool-to-agent framing is covered in designing APIs for AI agents.