MCP vs A2A: which one does your agent actually need?

MCP connects an agent to its tools and data. A2A connects agents to each other. Here is how each works in late 2026, how they fit together, and a simple way to decide which one your project needs.

Every agent project hits the same question sooner or later: should we expose this as an MCP server, build an A2A agent, or both? The two protocols get mentioned in the same breath so often that they can sound like competitors. They are not. They solve different problems, and since A2A joined in August 2026 they even live under the same roof: both are projects of the Linux Foundation's Agentic AI Foundation (AAIF).

The short answer

MCP connects one agent to its tools and data. Databases, APIs, file stores, SaaS apps. The agent stays in charge; the server just does what it is asked.
A2A connects one agent to another agent. The other side reasons, plans, keeps its own state, may take minutes or hours, and may come back with questions.
In my experience, most projects need MCP first. Reach for A2A when you have to work with an agent you do not control: another team, another company, another vendor's platform.

The A2A docs put it neatly: MCP is vertical and "deepens a single agent", while A2A is horizontal and "connects agents across that boundary".

Each agent uses MCP for its own tools. A2A is only the line between agents, usually across an organisational boundary.

MCP in late 2026

The Model Context Protocol is a JSON-RPC protocol between a host (the AI app), a client inside it (one per connection) and a server that exposes three kinds of things: tools (actions), resources (readable data) and prompts (templates). Local servers run over stdio; remote servers use Streamable HTTP, typically secured with OAuth.

The big change this year is the 2026-07-28 revision, which made MCP stateless. If you built servers in 2025, this is the part to read:

No more handshake or sessions. The initialize exchange and the Mcp-Session-Id header are gone. Every request carries its own protocol version and client capabilities in _meta, so any server instance behind a plain load balancer can answer any request.
server/discover is the new way to ask a server what it supports, whenever you need to.
State lives in handles. If a workflow spans several calls, the server returns an ID (a quote, a basket, a job) and the model passes it back as an ordinary tool argument.
Long-running work moved to the Tasks extension. A call can return a task handle; the client polls with tasks/get, sends extra input with tasks/update and can cancel with tasks/cancel.
Servers ask for more input by returning a result, not by calling the client. A result with resultType: "input_required" lists what is needed, and the client retries the original request with the answers.
Deprecated: Roots, Sampling, Logging, Dynamic Client Registration and the old HTTP+SSE transport. They are still in the spec, but some work differently now (for example, log level is set per request in _meta, and server requests for roots or sampling go through the new input-required pattern), so 2025-era code needs changes. The default deprecation window is twelve months; HTTP+SSE can be removed sooner.

This is the body of a tool call now. Note that it carries everything the server needs; nothing depends on an earlier message. (Over Streamable HTTP, the POST also carries Mcp-Method and Mcp-Name headers.)

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_stock_level",
    "arguments": { "sku": "TS-1042", "warehouse": "CMB-01" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {},
      "io.modelcontextprotocol/clientInfo": { "name": "sales-copilot", "version": "1.4.0" }
    }
  }
}

A2A in late 2026

Agent2Agent (A2A) started at Google, moved to the Linux Foundation and now has a stable 1.0 specification. By April 2026 the Linux Foundation counted more than 150 supporting organisations, with support in Azure AI Foundry, Copilot Studio and Amazon Bedrock AgentCore Runtime.

The moving parts:

Agent Card. A JSON document that says who the agent is, what it can do and how to reach it. The standard place to publish it is https://{your-domain}/.well-known/agent-card.json; registries and direct configuration also work.
Tasks. Work is a task with an ID and a lifecycle: submitted, working, then completed, failed, canceled or rejected. A task can also pause in input required or auth required, which is exactly what you want when the other agent needs a decision or a login from your side.
Messages, parts and artifacts. Agents exchange messages made of parts (text, files, structured data). Results come back as artifacts.
Three standard bindings: JSON-RPC, gRPC and HTTP+JSON. Streaming updates and push notifications are built in for long tasks.
Auth is declared, not improvised. The card lists the schemes it accepts: API key, HTTP auth, OAuth 2.0, OpenID Connect or mutual TLS.

A minimal Agent Card for a logistics partner's agent might look like this (security schemes left out for brevity):

{
  "name": "Delivery Planner",
  "description": "Books delivery slots and tracks shipments for wholesale orders.",
  "version": "1.2.0",
  "supportedInterfaces": [
    { "url": "https://agents.example-logistics.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["text/plain", "application/json"],
  "skills": [
    {
      "id": "book-delivery",
      "name": "Book a delivery slot",
      "description": "Finds and books the earliest delivery slot for an order.",
      "tags": ["delivery", "scheduling"],
      "examples": ["Book delivery for order 88123 to Kandy this week"]
    }
  ]
}

Side by side

	MCP	A2A
Connects	An agent to tools and data	An agent to another agent
The other side	Does what it is told	Reasons, plans, keeps its own state
Typical duration	Usually seconds	Seconds to days
Discovery	Configured in the host; `server/discover`	Agent Card at `/.well-known/agent-card.json` or a registry
Long work	Tasks extension	Built-in tasks, streaming, push
Asking back	`input_required` result, client retries	Task pauses in input or auth required
Best inside	One product or team	Across teams, companies, vendors
Home	AAIF (Linux Foundation)	AAIF (Linux Foundation)

How to decide

Ask these in order. The first "yes" usually settles it.

Are you giving a model access to a system: an API, a database, a SaaS app, a file store? Build an MCP server. This covers most enterprise work, such as putting a copilot on top of an ERP.
Are you splitting your own agent into sub-agents inside one codebase? Use neither. Plain function calls or your framework's sub-agents are simpler, faster and easier to debug. A2A adds network hops, auth and versioning you do not need.
Do you need to hand work to an agent someone else runs, which will make its own decisions and may take a while? That is A2A.
Do you want other companies' agents to be able to use yours? Publish an Agent Card and expose your agent over A2A. Keep your tools behind MCP inside your boundary.

In practice, a mature system often uses both. A sales copilot for a distributor reads orders and stock through an MCP server on the ERP, then asks the logistics company's agent over A2A to book delivery. The copilot never sees the logistics company's tools, and it does not need to.

Mistakes I keep seeing

Wrapping every API endpoint as an MCP tool. In my experience, models do better with a few task-shaped tools ("find customer and open orders") than with thirty thin CRUD endpoints. Design tools for the model, not for completeness.
Keeping session state in MCP servers. After 2026-07-28 this breaks behind a load balancer. Return a handle and let the model pass it back.
Passing the user's token straight through to downstream APIs. The MCP authorization spec forbids token passthrough. Validate the token as a resource server, and get a separate token for downstream APIs (for example, through an on-behalf-of exchange).
Trusting third-party tool descriptions. A tool description is text the model reads, which makes it a prompt-injection channel. Review servers before you connect them.
Using A2A for internal plumbing. If you control both sides and they ship together, you are paying for interoperability you will never use.

Where this is heading

Both protocols are still moving: most of MCP's newly deprecated features only become eligible for removal from July 2027, and A2A's first stable version is still young. My read of the direction: tools speak MCP, agents speak A2A, and the same foundation now steers both. If you are starting today, build your tool layer on the 2026-07-28 MCP spec, keep it stateless, and add A2A at the edges where your agent meets someone else's.

Sources