A2A vs MCP: two protocols solving two different problems

The one-line answer

MCP connects an agent to its tools. A2A connects an agent to another agent. MCP runs vertically — down from your agent into the databases, APIs and files it needs. A2A runs horizontally — across to a peer that has its own model, its own tools, and usually its own owner.

That is the whole distinction, and every other difference follows from it. If the thing on the other end is a capability you drive, you want MCP. If it is a system that decides for itself how to accomplish what you asked, you want A2A.

What each one actually puts on the wire

Abstract comparisons are easy to nod along with and hard to act on, so look at the messages instead. An MCP client, once connected to a server, asks what it can call:

--> {"jsonrpc": "2.0", "id": 1, "method": "tools/list"}

<-- {"jsonrpc": "2.0", "id": 1, "result": {
      "tools": [{
        "name": "search_orders",
        "description": "Find orders by customer id or date range",
        "inputSchema": {
          "type": "object",
          "properties": {
            "customerId": { "type": "string" },
            "since":      { "type": "string", "format": "date" }
          },
          "required": ["customerId"]
        }
      }]
    }}

Note the shape of that description. inputSchema is a contract for a caller that already knows what it wants: give me these arguments, I will do exactly this. The tool has no opinion, no state of its own worth speaking of, and no ability to come back later.

A2A opens with something quite different — a document, fetched over plain HTTP, describing an agent:

{
  "name": "Order Operations Agent",
  "description": "Investigates order issues end to end: locates the order,
                  diagnoses the failure, and issues refunds under policy.",
  "version": "2.4.0",
  "supportedInterfaces": [
    { "url": "https://agents.example.com/orders/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0" }
  ],
  "capabilities": { "streaming": true, "pushNotifications": true },
  "defaultInputModes": ["text/plain", "application/json"],
  "defaultOutputModes": ["application/json"],
  "skills": [{
    "id": "order-investigation",
    "name": "Order investigation",
    "description": "Given a customer complaint, find the order, determine
                    what went wrong, and propose or execute a remedy.",
    "tags": ["orders", "refunds", "support"]
  }]
}

There is no input schema here, and that absence is the point. You do not tell this agent which function to call — you hand it a problem in one of its defaultInputModes and it works out the rest. What the card promises instead is addressability: where the agent lives, what protocol it speaks, whether it can stream, whether it can call you back, and what kinds of problems it is willing to take.

Discovery is the real difference

The deepest split between the two protocols is not the message format — both lean on JSON-RPC 2.0 — but when and how you find out what exists.

MCP discovery is in-session. You connect to a server you were already configured to know about, complete an initialize handshake, and then ask it what it has. Nothing is discoverable before the connection exists, which is fine, because the host application already knows which servers it is wired to.

A2A discovery is static and public. The Agent Card sits at a fixed, well-known path and is fetched with an ordinary unauthenticated GET:

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

That single design decision is what makes A2A work across organisational boundaries — which is the problem A2A was introduced to solve. Anyone who knows your domain can learn what your agent does without a credential, an SDK, a registry entry or a conversation with your team. It is the same trick robots.txt and openid-configuration pull, applied to agents — and it is why the card carries so much weight in the protocol.

Side by side

Where the comparison is genuinely a choice

There is a real overlap, and pretending otherwise is how people end up building the wrong thing. Both protocols can carry JSON-RPC over HTTP. Both describe capabilities as JSON. And you can wrap an entire agent as a single MCP tool called ask_the_orders_agent, or expose a single tool as a trivial A2A agent with one skill. Neither is absurd.

Three questions usually settle it:

1. Does the caller know the exact operation it wants? If yes, that is a tool call, and MCP's typed input schema is a feature rather than a formality.
2. Does the work outlive a single request? Tasks that run for minutes, need progress updates, or call back later fit A2A's task lifecycle; forcing them through a synchronous tool call means building your own polling protocol on the side.
3. Does a stranger need to find this? If a team you have never met should be able to discover and address your agent, only A2A gives you that for free. MCP has no equivalent of a public, crawlable card.

The stack that runs both

In practice the interesting systems are not choosing. A single deployed agent is usually an A2A peer on the outside and an MCP client on the inside:

• Its public face is an Agent Card at /.well-known/agent-card.json, so partner agents can find it, see which skills it offers, and learn how to authenticate.
• Behind that endpoint, the agent reaches its warehouse database, its payments API and its document store through MCP servers — none of which are visible to, or the business of, the caller.
• When it needs work it cannot do itself, it fetches another agent's card and delegates over A2A, becoming a client at that boundary.

The layering is what makes the encapsulation hold. A partner integrating with your agent should not need to know that you swapped one MCP tool for another last week, and with this structure they never find out.

Which one to reach for

Reach for MCP when you are extending what a single agent can do:

• giving a model access to a database, a filesystem, a ticketing system or an internal API;
• packaging a deterministic operation you want called with specific arguments;
• working entirely inside one trust domain, where a configured connection is a reasonable prerequisite.

Reach for A2A when you are making an agent reachable as a participant:

• another team, product or company needs to send work to your agent;
• the work is open-ended enough that the caller should describe the goal, not the procedure;
• you want to be listed, indexed or discovered rather than individually integrated.

If that second list describes you, the first artefact to build is the card itself — the shape of it is defined in the A2A specification — and it is smaller than the integration work you are probably imagining. The Agent Card schema reference walks every field of the v1.0 document, and the Agent Card generator will produce a valid one from a form in about two minutes. When you have a draft, run it through the validator before it goes anywhere near a partner.