A2A vs MCP: which one do you need?

MCP (Model Context Protocol) connects an AI application to the tools, data and prompts it uses. A2A (Agent2Agent) connects an agent to another agent that runs its own logic, often for a different team or company. If your agent needs to call a function or read a data source, you need MCP. If it needs to hand a job to an independent agent and track that job to the end, you need A2A.

The two fit together: A2A between agents, MCP inside each agent. The A2A specification describes that arrangement in an appendix, and Google’s April 2025 announcement of A2A called it complementary to MCP.

What MCP is for

Anthropic introduced MCP in November 2024 as an open standard for connecting AI assistants to the systems where data lives. It is now organized as a series of LF Projects, LLC, under the Linux Foundation umbrella. Its maintainers hold their roles as individuals, and no seats are reserved for companies.

MCP has three roles:

• Host. The AI application, such as an IDE or a chat app. It manages connections, enforces consent, and holds the conversation.
• Client. A connector inside the host. Each client talks to exactly one server.
• Server. A service that exposes capabilities to the host.

Servers offer three kinds of features: tools (functions the model can call), resources (context and data) and prompts (templated messages). Clients can offer elicitation, which lets a server ask the user for more information. The model decides when to call a tool, and the specification says a human should be able to deny any tool call.

Current version and transports

MCP versions are dates that mark the last backward-incompatible change. The current version is 2026-07-28. In this revision MCP is stateless: every request carries its own protocol version and client capabilities in a _meta field, and servers describe themselves through a server/discover call. Revisions up to 2025-11-25 used an initialize handshake and a connection-scoped session, and the specification describes how to interoperate with them.

Two standard transports carry MCP’s JSON-RPC 2.0 messages:

Transport	How it works	Typical use
stdio	Newline-delimited JSON-RPC over the standard input and output of a subprocess that the client launches	Local servers on the user’s machine
Streamable HTTP	Each message is an HTTP POST to one MCP endpoint; the reply is a JSON object or a request-scoped Server-Sent Events stream	Remote servers

Custom transports are allowed if they keep the JSON-RPC format and message patterns. Authorization is optional. When an HTTP server uses it, MCP follows an OAuth 2.1 profile in which the MCP server acts as the resource server. A stdio server takes its credentials from the environment instead.

For work that takes minutes or hours, MCP has an opt-in Tasks extension. The server returns a durable task handle, and the client polls it, answers input_required requests, or cancels it.

What A2A is for

Google announced A2A in April 2025, and the Linux Foundation launched the Agent2Agent project in June 2025. The current version is 1.0. A2A treats agents as opaque peers: each side sees only what the other declares and returns, never its internal memory, tools or plans.

A2A gives two agents:

• Discovery through an Agent Card, usually published at /.well-known/agent-card.json on the agent’s domain.
• Tasks with a server-assigned ID and a lifecycle that includes pauses for more input (TASK_STATE_INPUT_REQUIRED) or authorization (TASK_STATE_AUTH_REQUIRED).
• Messages and artifacts built from text, file and structured-data parts.
• Updates by polling, streaming, or push notifications to a webhook.
• Three bindings: JSON-RPC 2.0, gRPC and HTTP+JSON, all mapped from one Protocol Buffers data model.

The full picture is in What is the A2A protocol?.

Side by side

	MCP	A2A
Connects	An AI application to tools, data and prompts	An agent to another agent
The other side is	A server exposing defined capabilities	An autonomous agent that decides how to do the work
Finding it	The host connects to servers it is configured with; server/discover and tools/list describe what a server offers	Agent Card at a well-known URI, a registry, or direct configuration
Unit of work	A request, such as tools/call; the Tasks extension adds durable handles for long runs	A task with a lifecycle, built into the core protocol
Input	Tool arguments that match a JSON Schema	Messages with text, file and data parts
Output	Content blocks and optional structuredContent	Artifacts, plus status messages
Wire format	JSON-RPC 2.0	JSON-RPC 2.0, gRPC or HTTP+JSON
Transports	stdio, Streamable HTTP	HTTP(S); HTTP/2 for gRPC
Updates on long work	Polling or notifications, through the Tasks extension	Polling, streaming, or push webhooks
Authentication	Optional; OAuth 2.1 profile for HTTP	Schemes declared in the card: API key, HTTP auth, OAuth 2.0, OpenID Connect, mutual TLS
Versioning	Date-based; current 2026-07-28	Major.Minor in an A2A-Version header; current 1.0

The same request, two ways

Illustrative: an agent needs a freight quote. The two requests below show how the protocols differ in intent.

With MCP, the caller picks a specific function and fills in its arguments. The _meta request metadata is omitted here, as the MCP specification’s own examples do.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "get_freight_rate",
    "arguments": {
      "origin": "Toronto, ON",
      "destination": "Chicago, IL",
      "pallets": 40
    }
  }
}

With A2A, the caller states a goal to an agent that belongs to someone else. That agent chooses how to meet it, can ask a follow-up question, can decline, and returns a task the caller can track.

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "SendMessage",
  "params": {
    "message": {
      "messageId": "0e6b3a52-94c1-4f7d-a2e8-5b9c1d3f7a20",
      "role": "ROLE_USER",
      "parts": [
        { "text": "Quote 40 pallets from Toronto to Chicago, pickup Monday. Hold the rate for 24 hours if you can." },
        {
          "data": { "origin": "Toronto, ON", "destination": "Chicago, IL", "pallets": 40 },
          "mediaType": "application/json"
        }
      ]
    }
  }
}

The MCP call returns a result from a function that the caller chose. The A2A call returns a task whose outcome the remote agent controls. It may complete, move to TASK_STATE_INPUT_REQUIRED with a question about the pickup window, or end in TASK_STATE_REJECTED.

How they fit together

The A2A project describes MCP as vertical and A2A as horizontal. MCP adds depth to one agent by giving it more tools and data. A2A adds reach by connecting that agent to agents outside its own boundary.

Illustrative flow for a buyer requesting a quote:

1. The buyer’s procurement agent reads a supplier’s Agent Card and sends the request over A2A.
2. The supplier’s quoting agent accepts the task. Inside, it uses MCP to call its inventory database and its rate calculator.
3. The quoting agent returns the quote to the buyer’s agent as an A2A artifact.
4. The buyer’s agent never sees the supplier’s tools. The supplier’s tools never see the buyer.

Decision table

If you need to…	Use	Why
Let your agent query a database, call an API or read files you control	MCP	You define the functions and their schemas
Let AI applications use features of your product	MCP server	Hosts connect to it and call its tools
Hand work to an agent that another team or company runs	A2A client	The other side keeps its own logic and policy, and you track a task
Make your own agent reachable by outside agents	A2A server with an Agent Card	Clients discover your skills, bindings and auth requirements
Run a long job against a tool, with approval steps	MCP with the Tasks extension	Durable handles, polling and input_required
Run a long, multi-turn job with another agent	A2A	Task states, streaming and push are part of the core protocol
Both of the above	Both	A2A between agents, MCP inside each one

Scenarios

Illustrative: internal analytics assistant. A company’s assistant answers questions about sales data. It reads a warehouse and a metrics API. Everything it touches is a tool the company controls. MCP alone covers this.

Illustrative: travel rebooking. A traveler’s assistant needs an airline to rebook a canceled flight. The airline’s own agent applies fare rules and seat inventory, and it may need to ask which alternative the traveler prefers. The assistant reaches it over A2A. Internally, the airline’s agent may use MCP to reach its reservation system.

Illustrative: software vendor. A vendor wants AI applications to create and update records in its product. It builds an MCP server. Later it adds a support agent that resolves multi-step cases for other companies’ agents, and publishes an A2A Agent Card for that agent.

Common misconceptions

“A2A and MCP compete.” They address different layers. Google introduced A2A as complementary to MCP, and the A2A specification includes an appendix on how the two work together.

“Wrapping an agent as an MCP tool gives you the same thing.” For narrow, stateless skills it can work, and the A2A documentation notes that an A2A server can expose such skills in a tool-like form. You lose the task lifecycle, mid-task questions, and the remote agent’s freedom to decide how to do the work.

“MCP can’t handle long-running work.” The Tasks extension adds durable task handles, polling, mid-flight input and cancellation. Both client and server must opt in.

“MCP needs a long-lived session.” The 2026-07-28 revision is stateless. Each request carries its own version and capabilities. Older revisions used a session opened by an initialize handshake.

“A2A is tied to one vendor’s stack.” A2A is a Linux Foundation project. Its bindings use HTTP, JSON-RPC 2.0 and gRPC, and it makes no assumption about how an agent is built.

“Using either protocol proves who the other side is.” Both rely on standard web authentication, which tells you a caller holds a valid credential. Neither tells you whether the organization behind a server or agent is trustworthy. The MCP specification tells clients to treat tool descriptions and annotations as untrusted unless the server is trusted. An A2A card signature proves which key signed the card. It says nothing about whether the key’s owner is reputable.