MCP vs A2A: How AI Agent Protocols Differ

MCP and A2A show up in the same sentence constantly. Most explanations blur the two together. Both are protocols, and both were built for AI agents. Instead, they solve two separate problems.

This guide sticks to spec-accurate mechanics, not marketing language. So it walks through what each protocol actually defines: message formats, discovery steps, and the exact shape of a request. Every claim traces back to the official specification, not a summary of one.

The short version: MCP and A2A sit on different axes of one system. MCP reaches down, from an agent into its tools. A2A reaches sideways, from one agent to another. That direction alone explains most of what follows.

Why Agent Protocols Exist At All

Before MCP or A2A, every AI application wrote its own tool integrations. An app needing a calendar, a database, and a search tool wrote three separate pieces of glue code. Add a second application, though, and none of that code carries over.

This is the classic N×M problem. N applications, each needing M tools, add up to N×M integrations. So nothing standard sits between them. So every new tool means new code in every application. Likewise, every new application means rebuilding every integration from scratch.

The same multiplication happens between agents, not only between an agent and its tools. Suppose one team’s agent needs to delegate to another team’s agent, built on a different framework. Someone still has to write custom translation code for that one pairing. Multiply that across many independently built agents, and glue code becomes the real bottleneck.

MCP and A2A each remove one side of that multiplication. MCP gives an application one client that reaches any compliant tool server. So the N×M tool problem collapses to N+M. A2A gives an agent one client that reaches any compliant peer agent, regardless of vendor or framework. This mirrors how networking solved a similar problem decades earlier; see OSI model vs TCP/IP model for how layered protocols replaced one-off wiring between systems.

What MCP Does

MCP stands for Model Context Protocol. Anthropic built it and open-sourced it in November 2024. Its job is narrow: connect one AI application to the external tools and data it needs.

The architecture has three roles: host, client, and server. A host is the application itself, such as an IDE. The host runs one or more clients. Each client holds a single connection to one server. A server exposes context and capabilities over that connection, and it can run locally or sit somewhere remote.

Servers offer three primitives to the client. Tools are functions the model can invoke, such as a search call. Resources are contextual data for the model to read, instead of code the model runs. Prompts are templated messages a user can select directly.

Messages travel as JSON-RPC 2.0. Local servers typically use stdio. The client launches the server as a subprocess. Then it exchanges messages over standard input and output. Remote servers use Streamable HTTP instead. They post JSON-RPC requests to one endpoint, and the response can stream back. Coding agents such as the ones compared in Claude Code vs GitHub Copilot already lean on this exact mechanism. It lets them reach editor and filesystem tools.

Discovery happens at runtime, not at build time. A client sends a tools/list request. It gets back the exact tools a server currently offers, with a schema for each tool’s inputs. It then calls a chosen tool with tools/call. None of this requires the client to know a server’s tools in advance. So a server can add or remove tools without breaking any client that talks to it.

What A2A Does

A2A stands for Agent2Agent. Google introduced it in April 2025. Google later donated it to the Linux Foundation. Where MCP connects an agent to its tools, A2A connects one agent to another agent instead.

Discovery starts with the Agent Card. A remote agent publishes this as a JSON document. It sits at a fixed, well-known location: /.well-known/agent-card.json on the agent’s domain. The card lists the agent’s identity, its service endpoint, and the skills it offers. It also lists declared capabilities, such as streaming, and the authentication schemes a caller must use.

Once a client agent reads that card, it sends work as a task. A task is the basic unit of work in A2A. Each task carries its own id. It moves through defined states, such as submitted, working, input-required, and completed. Because the task keeps a persistent identity across the exchange, both sides can check its status later. So neither side needs to hold one long connection open.

Requests carry messages, and messages carry parts. A part can be plain text, a file, or structured data. So a single message can mix a question with an attachment. When a task finishes, the output comes back as one or more artifacts. So each artifact is built from the same kind of parts.

Transport is JSON-RPC 2.0 over HTTPS. Streaming is available over server-sent events. It requires the Agent Card to declare that support. Since reaching version 1.0 in March 2026, the spec also defines gRPC and REST bindings. Both still sit over the same underlying data model. Even so, JSON-RPC remains the most common choice in practice.

A defining principle runs through all of this: opacity. Instead, agents collaborate through declared capabilities and exchanged messages only. Neither side has to expose its internal reasoning, its memory, or the tools it uses behind the scenes.

MCP vs A2A: Comparison Table

How They Work Together

Consider a travel-planning agent. A user asks it to book a flight. The agent does not know how to talk to any specific airline. Instead, it delegates that part of the job to a specialist agent, run by someone else entirely.

The travel agent acts as an A2A client here. To begin with, it fetches the flight-booking agent’s Agent Card from its well-known URL. It then confirms the agent supports the skill it needs. Then it sends a task describing the trip: origin, destination, and dates. The remote agent accepts the task and moves it into a working state.

Internally, the flight-booking agent is also an MCP host. To search real fares, it opens an MCP client connection to an airline’s MCP server. It calls a search tool over tools/call. The MCP server queries the airline’s real booking API. It then returns structured results back through the same connection.

So the flight-booking agent turns that result into a task artifact. It marks the task completed. The travel agent receives the artifact over A2A. It folds the result into the itinerary shown to the user. Notice what stayed private. The travel agent never learned which MCP server the specialist used, nor which tool, nor how the search worked internally. Only the declared skill and the final result crossed the A2A boundary. That is the opacity principle in action.

The two protocols also differ in how they hold state across that exchange. It helps to be precise here, rather than waving at state in general; see stateless vs stateful protocols for the broader distinction this maps onto. The A2A task persists with its own id and status for as long as the booking takes. The MCP call underneath it, in contrast, is self-contained at the protocol level. It carries no session for the airline server to maintain between calls.

What the Messages Look Like

Seeing the two message shapes side by side makes the difference concrete. Here is a trimmed MCP tool call. It travels as JSON-RPC over Streamable HTTP or stdio:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "search_flights",
    "arguments": {
      "origin": "JFK",
      "destination": "LHR",
      "date": "2026-09-10"
    }
  }
}

The server replies with a plain tool result, scoped to that one call:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "content": [
      { "type": "text", "text": "3 fares found, from $412." }
    ],
    "isError": false
  }
}

Both examples above drop the _meta block for brevity. Every real MCP request must carry it, because that is where the protocol version and client capabilities travel.

Now compare an A2A message. A client agent sends a task with message/send:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [
        { "kind": "text", "text": "Book the cheapest JFK-LHR flight on 2026-09-10." }
      ],
      "messageId": "9229e770-767c-417b-a0b0-f0741243c589"
    }
  }
}

The remote agent responds with a task object, not a bare result:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "id": "363422be-b0f9-4692-a24d-278670e7c7f1",
    "contextId": "c295ea44-7543-4f78-b524-7a38915ad6e4",
    "status": { "state": "completed" },
    "artifacts": [
      {
        "artifactId": "9b6934dd-37e3-4eb1-8766-962efaab63a1",
        "name": "booking-confirmation",
        "parts": [
          { "kind": "text", "text": "Booked: JFK-LHR, 2026-09-10, $412." }
        ]
      }
    ]
  }
}

Look at the shape difference, not just the field names. The MCP response answers one call, and nothing more. The A2A response, in contrast, carries an id, a status, and an array of artifacts. That is because a task is a tracked object, not a single reply.

When You Need Which

Reach for MCP when an agent needs a new capability. That could be a database, a search index, or an internal API. Frameworks such as those compared in LangChain vs LlamaIndex still need a protocol like MCP to reach the outside world. In short, neither framework replaces that layer on its own.

Reach for A2A when the work needs delegating to a separate agent. This matters most for an agent built by another team or vendor. It matters even more once agents start making real decisions, not just following a script; see AI agents vs traditional automation for why that shift changes what an integration must preserve.

Most nontrivial systems need both protocols at once. An agent typically talks sideways to peers over A2A. At the same time, it reaches down into its own tools over MCP. That is exactly what the travel-booking example above shows. Treating this as a choice between the two protocols misses how they actually get used.

Interview Questions

Frequently Asked Questions

Wrapping Up

MCP and A2A answer two separate questions, not the same one twice. MCP gives an agent a standard way to reach its own tools, data, and prompts. A2A, meanwhile, gives an agent a standard way to hand work to another agent. It does that without exposing what happens on either side.

Remember the essentials for real systems, not just for an exam. Direction is the fastest way to tell them apart: MCP runs vertically, A2A runs horizontally. Because most working deployments need both layers, the honest framing is never MCP versus A2A. It is MCP and A2A, doing two different jobs in the same system.

Related reading on DiffStudy:

• Stateless vs Stateful Protocols
• OSI Model vs TCP/IP Model
• AI Agents vs Traditional Automation
• LangChain vs LlamaIndex
• CS Fundamentals hub