A2A vs MCP: Differences, Use Cases and How They Fit

MCP (Model Context Protocol) connects one AI application to tools, data and prompts: the model calls a function such as search_issues and gets a structured result back. A2A (Agent2Agent) connects one agent to another, independent agent: you hand a whole task to a peer you cannot see inside, and it reports progress and results back. They are not competitors. Most real systems that use A2A also use MCP, with MCP inside each agent and A2A between agents.

The A2A project's own docs put it in one line: MCP is vertical, A2A is horizontal. MCP makes a single agent more capable. A2A lets that agent reach agents owned by other teams, vendors or companies. If you are new to MCP itself, start with What is MCP? and come back.

A2A vs MCP at a glance

The row that matters most is "what the other side is". An MCP server exposes functions with input schemas, so the model knows exactly what it is calling. An A2A agent exposes skills described in plain language and keeps its internals private: its prompts, tools, memory and even which model it runs on.

What MCP does

MCP standardizes how an AI application (the host, such as Claude Code, Cursor or ChatGPT) talks to servers that provide context and actions. A server exposes three kinds of primitives: tools the model can call, resources the app can read as context, and prompts the user can trigger. See What is an MCP server? for the server side and How does MCP work? for the message-by-message lifecycle.

Two facts are worth knowing in 2026:

• The current spec, revision 2026-07-28, made MCP stateless. The initialize handshake is gone. Every request carries its protocol version and client capabilities in _meta, and servers advertise themselves through server/discover.
• Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, on December 9, 2025.

A tool call looks like this (from the official architecture guide):

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "San Francisco", "units": "imperial" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": { "elicitation": {} }
    }
  }
}

The result is a content array (and optionally structuredContent) with "resultType": "complete". The model chose the tool, filled in the arguments against a JSON Schema, and got data back. Nothing about it is agent-like on the server side.

What A2A does

A2A standardizes how one agent asks another agent to do work. Google announced it at Cloud Next in April 2025 with more than 50 partners, donated it to the Linux Foundation in June 2025, and the first stable version, 1.0.0, shipped on March 12, 2026. In August 2025 IBM's Agent Communication Protocol (ACP) merged into A2A, so there is now one Linux Foundation agent-to-agent standard rather than two. At its one-year mark the Linux Foundation reported more than 150 supporting organizations.

The core objects in the A2A specification are:

• Agent Card: a JSON document describing the agent's name, skills, supported interfaces, capabilities (streaming, push notifications) and security schemes. Public cards live at https://{domain}/.well-known/agent-card.json. Version 1.0 also supports signed cards.
• Task: the unit of work, with states such as TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED, TASK_STATE_AUTH_REQUIRED, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED and TASK_STATE_REJECTED.
• Message and Part: conversational turns made of text, file or data parts.
• Artifact: the output the remote agent produces, such as a report or a file.

The operations are SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, the push notification config methods and GetExtendedAgentCard. Clients send an A2A-Version header (for example 1.0) on each request.

Here is the spec's own example over the HTTP+JSON binding: a client asks a question and gets back a completed task.

POST /message:send HTTP/1.1
Host: agent.example.com
Content-Type: application/a2a+json
Authorization: Bearer token

{
  "message": {
    "role": "ROLE_USER",
    "parts": [{"text": "What is the weather today?"}],
    "messageId": "msg-uuid"
  }
}

{
  "task": {
    "id": "task-uuid",
    "contextId": "context-uuid",
    "status": { "state": "TASK_STATE_COMPLETED" },
    "artifacts": [
      {
        "artifactId": "artifact-uuid",
        "name": "Weather Report",
        "parts": [{ "text": "Today will be sunny with a high of 75°F" }]
      }
    ]
  }
}

Compare the two payloads. MCP sends a function name with typed arguments. A2A sends a message in natural language and gets back a task with an ID, a context and artifacts. The remote agent decides how to get the answer.

When to use MCP, when to use A2A

Use MCP when:

• You want your assistant or agent to read or change something: a repo, a database, a ticket tracker, a browser. Popular examples include the GitHub MCP server, Postgres MCP and Playwright MCP.
• The capability has clear inputs and outputs and needs no reasoning of its own.
• You want it to work in the clients people already use. Claude, ChatGPT, Cursor, VS Code and Codex all speak MCP. See the client list.

Use A2A when:

• The thing you are calling is itself an agent with its own model, tools and judgment, and you want to delegate a goal, not a function call.
• The other agent belongs to another team, vendor or company, and they will not (or should not) expose their internals.
• The work is long-running or multi-turn: the remote agent may need more input (TASK_STATE_INPUT_REQUIRED), extra auth, or hours to finish, with progress streamed back or pushed to a webhook.

A quick test: if you could describe the capability as a function signature, it is an MCP tool. If you would describe it as "ask the billing team's agent to sort this out", it is an A2A call.

How A2A and MCP work together

The A2A spec's appendix on MCP describes the standard pattern: an A2A client agent asks an A2A server agent to do a complex task, and the server agent uses MCP to reach the tools, APIs and data it needs to finish.

A concrete example, a travel booking flow:

1. A user asks a travel agent (built in any framework) to plan a trip.
2. The travel agent reads the Agent Cards of a flight agent and a hotel agent run by partners, and sends each a task over A2A.
3. Inside, the flight agent uses MCP servers for its airline inventory API and a payments service. The hotel agent does the same with its own MCP servers.
4. The hotel agent hits TASK_STATE_INPUT_REQUIRED ("Do you want breakfast included?"), and the travel agent answers in the same contextId.
5. Both tasks complete with artifacts (itineraries), which the travel agent merges for the user.

The travel agent never sees the airline API, and the flight agent never sees the user's conversation. MCP gives each agent depth; A2A gives the system reach.

You can also go the other way and wrap a remote agent as an MCP tool, so an MCP-only client like an IDE can call it. That works for quick, single-shot requests. But you lose A2A's task lifecycle, multi-turn input and push notifications, so for real delegation, use A2A directly.

Common misconceptions

• "A2A replaces MCP." No. Google launched A2A as a complement to MCP, and both are now Linux Foundation projects. Their scopes barely overlap.
• "MCP can't do agent-to-agent." An MCP server can have an LLM behind it, and MCP has elicitation and an optional Tasks extension for long jobs. But MCP has no Agent Cards, no peer task lifecycle and no notion of opaque agents with skills. It was designed for tools and context.
• "You need both from day one." Most teams only need MCP. A2A matters once you have several agents owned by different parties that must cooperate.
• "They're both just JSON-RPC, so they're the same." Sharing a wire format says little. MCP is built around schemas and model-controlled calls. A2A is built around tasks, messages and artifacts between peers.
• "ACP is a third standard I must support." IBM's ACP merged into A2A in 2025. The unrelated Agent Client Protocol (editor to coding agent) shares the abbreviation, so check which one people mean.

Next steps

If you are building one capable agent, start with MCP: browse the MCP.so server directory for ready-made integrations, compare MCP with retrieval in MCP vs RAG, and read How does MCP work? to understand the protocol underneath. Add A2A when your agent needs to hand whole tasks to agents someone else runs.