MCP vs A2A: which agent protocol does what

Two protocols dominate the agent ecosystem in 2026 and people keep confusing them. Model Context Protocol (MCP) and Agent-to-Agent (A2A) sound like alternatives. They are not. They solve different problems and most non-trivial agent systems end up shipping both.

This guide is the practical mental model and a deployment cheat sheet.

The one-sentence answer

MCP lets a single AI assistant call your tools, read your data, and run your prompts. The connection is one assistant to many tool servers.
A2A lets one agent delegate work to another agent. The connection is agent to agent, peer to peer.

If MCP is the USB cable, A2A is the phone call.

When you want MCP

You are exposing your application as a set of capabilities for someone else's AI assistant to call. Examples:

A SaaS product that wants to be reachable from Claude Desktop, Cursor, ChatGPT Apps, or any future assistant.
An internal database team exposing read-only queries to a company-wide AI assistant.
A docs platform exposing search to AI coding tools.

You ship an MCP server. The assistant is the MCP client.

The protocol is JSON-RPC over WebSocket, stdio, or HTTP. The wire format and lifecycle are public and stable.

When you want A2A

You are building an AI agent that needs to call other AI agents. Examples:

A research agent that delegates document summarization to a specialized agent.
A purchasing agent that hands off price negotiation to a vendor's negotiation agent.
A workflow agent that routes a task across several internal agents owned by different teams.

You ship an A2A endpoint. Your agent is the producer; another agent is the consumer.

The protocol is also JSON-RPC, but the units are higher-level: tasks, artifacts, and turn-taking. Agents can stream, push notifications, and persist state across turns.

A practical decision tree

Are you exposing capabilities to an AI assistant the user controls? Ship MCP.
Are you building an agent that calls other agents? Ship A2A.
Are you doing both? Ship both. They compose.

A real-world combination: an A2A agent that internally calls MCP servers to access tools, and exposes itself to other A2A agents as a single specialty.

Discovery convention

This is where the protocols overlap with the rest of the agent web.

MCP discovery

MCP servers commonly live at /mcp directly. The convention is in flux as of 2026, with /.well-known/mcp increasingly proposed.

A2A discovery

A2A servers publish an agent card at /.well-known/agent-card.json. The card is a JSON document describing the agent's identity, capabilities, skills, and authentication.

{
  "name": "Acme Support Agent",
  "description": "Answers product questions and creates support tickets.",
  "url": "https://example.com/a2a",
  "version": "1.0.0",
  "provider": {
    "organization": "Acme Inc",
    "url": "https://example.com"
  },
  "capabilities": {
    "streaming": true,
    "pushNotifications": false,
    "stateTransitionHistory": false
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain"],
  "authentication": { "schemes": ["bearer"] },
  "skills": [
    {
      "id": "answer_question",
      "name": "answer_question",
      "description": "Answer a question about Acme products."
    },
    {
      "id": "create_ticket",
      "name": "create_ticket",
      "description": "Open a support ticket."
    }
  ]
}

Build one with the Agent Card Builder.

Authentication models

Both protocols delegate auth to existing standards.

MCP: increasingly supports OAuth 2.1 with PKCE. Many implementations accept bearer tokens directly. The specifics depend on the transport.
A2A: declares the auth scheme in the agent card. Common schemes: none, bearer, apiKey, oauth2.

Both protocols benefit from /.well-known/oauth-protected-resource advertising which authorization server issues tokens for them.

Where each protocol struggles

MCP

Tool discovery is great inside an assistant; it is harder to surface tools across assistants without a registry.
The transport landscape (stdio, SSE, streamable HTTP) has changed several times. Pin a version.
There is no native cross-server auth coordination yet. Each MCP server stands alone.

A2A

Adoption is still skewed toward large platforms. Many smaller "agents" still expose simple HTTP APIs, not A2A endpoints.
Defining skills well is hard. Vague skills produce vague delegation.
The state model is rich, but most early adopters use only the synchronous request/response subset.

When neither protocol applies

Sometimes you just need an HTTP API with OpenAPI. That is fine. Use:

A clean OpenAPI document at a stable URL.
An RFC 9727 api-catalog at /.well-known/api-catalog listing it.
Standard auth (OAuth 2.0 or API key).

If a future agent ecosystem wants to consume your API, it can adapt. Build it with the API Catalog Builder.

A combined deployment pattern

The setup we see most in 2026 looks like this.

Your platform
├── /api/v1            (regular REST API)
├── /openapi.json      (OpenAPI doc for the REST API)
├── /mcp               (MCP server exposing tools)
├── /a2a               (A2A agent endpoint)
└── /.well-known/
    ├── api-catalog    (RFC 9727 list of REST APIs)
    ├── agent-card.json (A2A agent card)
    └── openid-configuration (OAuth discovery)

Each layer addresses a different audience. REST for backend integrations, MCP for assistants, A2A for other agents, OpenAPI for any developer.

What to ship this quarter

If you have to pick one to start, pick the one that matches your audience.

B2B SaaS with users who already use Claude or Cursor: ship MCP first.
Internal automation team building a multi-agent workflow: ship A2A first.
Public API with no agent ambition: ship the api-catalog and skip both for now.

You can always add the other later. The protocols are designed to coexist.

Why this matters

Both protocols are converging on the same vision: an addressable, callable, machine-readable web. Sites that participate get cited, called, and integrated into emerging agent workflows. Sites that do not participate get summarized at best and skipped at worst. The work to ship a basic MCP server or A2A endpoint is a few hours. The choice is which direction your audience is coming from.