MCP vs A2A: The Two Protocols in Every 2026 Agent Stack, Explained

Two protocols, two different problems

The fastest way to sound confused in an AI system design interview is to treat MCP and A2A as competitors. They standardize different boundaries of an agent system. Model Context Protocol (MCP), introduced by Anthropic and now adopted across the major model providers, standardizes the vertical boundary: how a single agent (or the application hosting it) connects to tools, data sources, and prompts. Agent2Agent (A2A), started by Google and now under the Linux Foundation, standardizes the horizontal boundary: how one autonomous agent discovers and delegates work to another autonomous agent, potentially owned by a different team or company.

A useful mental model: MCP is USB for a single agent — one standard port replacing a drawer full of proprietary tool integrations. A2A is HTTP between agents — a wire contract that lets two black boxes cooperate without reading each other's source code. A production agent platform in 2026 typically speaks both: MCP downward into tools, A2A sideways to peer agents.

What MCP actually standardizes

An MCP server exposes three primitive types to any connected client: tools (functions the model can call, with JSON-schema arguments), resources (readable context like files, tables, or documents, addressed by URI), and prompts (reusable templates the server offers the client). The client — Claude Desktop, an IDE, or your own agent harness — connects over stdio or HTTP, lists what the server offers, and mediates model access to it.

The architectural consequence: tool integrations stop being N×M glue code. Before MCP, every agent framework wrote its own Slack connector, its own Postgres connector, its own GitHub connector. With MCP, the Slack connector is written once as a server, and every MCP-speaking client can use it. In interviews, this is the "why does the protocol exist" answer: it converts an N×M integration matrix into N+M.

// A tool as an MCP server advertises it
{
  "name": "query_orders",
  "description": "Run a read-only SQL query against the orders database",
  "inputSchema": {
    "type": "object",
    "properties": {
      "sql": { "type": "string", "description": "SELECT statement only" }
    },
    "required": ["sql"]
  }
}

What A2A actually standardizes

A2A assumes both sides are full agents — opaque, autonomous, possibly long-running. The protocol gives them four things: discovery via Agent Cards (a JSON manifest describing skills, endpoints, and auth), a task lifecycle (submitted → working → input-required → completed/failed) so a client agent can track long-running delegated work, message exchange with typed parts (text, files, structured data), and streaming/push updates for tasks that take minutes or days.

The key design decision to cite in interviews: A2A deliberately does NOT expose the remote agent's internals — no prompts, no chain-of-thought, no tool list. You delegate a task and receive artifacts. That opacity is what makes it viable across organizational boundaries, the same way REST APIs hide implementations.

How they compose in one architecture

Picture a customer-support platform. A supervisor agent receives a ticket. It uses MCP to read the customer record from a CRM server and search past tickets in a vector store. Deciding a refund is needed, it uses A2A to delegate to the finance team's refund agent — a separate deployment with its own approval logic. That agent internally uses MCP to call the payments API, then reports completion back over A2A.

Notice the layering: MCP appears wherever an agent touches concrete capability; A2A appears wherever autonomy crosses a boundary. When an interviewer asks "when would you use A2A instead of just giving the supervisor another tool?", the answer is ownership and autonomy: refunds have their own policy, their own audit trail, their own team on call. Wrapping that as a "tool" hides an entire responsible subsystem behind a function signature; delegating to it as an agent keeps the boundary honest.

The follow-up questions interviewers ask

"What breaks without idempotency?" A2A tasks can be retried after network failures; if the remote agent executes side effects non-idempotently, retries double-charge or double-email. Task IDs must deduplicate.

"How do you secure it?" Agent Cards declare auth requirements; in practice that means OAuth-style service credentials plus per-skill authorization — the finance agent refuses refund tasks from unauthorized peers regardless of what the request claims.

"What about latency?" MCP tool calls are milliseconds-to-seconds and synchronous. A2A tasks are designed to be minutes-to-days and asynchronous — the lifecycle states and push notifications exist precisely because blocking on a peer agent is unacceptable. Choosing the wrong protocol for the interaction's time scale is a design smell interviewers probe for.

Practice it like an interview

Our AI Agent Orchestration case study walks the full architecture — durable runs, idempotent tools, budget governors — with interviewer pressure questions and model answers. The RAG Pipeline case study covers the retrieval layer most MCP resource servers front. Both follow the same 10-step framework as every system design case study on this site.