MCP vs A2A: Which Agent Protocol Do You Need?

Two protocols dominate conversations about agent interoperability, and they are routinely confused because both have "agent" in the pitch. They solve different problems at different layers, and the confusion leads teams to build agent-to-agent systems when a function call would do.

The One-Line Versions

MCP (Model Context Protocol) connects an agent to tools and data. A server exposes tools, resources, and prompts; a client discovers and calls them. Vertical: model to capability.

A2A (Agent-to-Agent) connects an agent to other agents. Each agent publishes an agent card describing what it does; another agent discovers it, sends it a task, and receives results, possibly over a long-running exchange. Horizontal: agent to agent.

A typical multi-agent system uses both: MCP under each agent for its tools, A2A between agents. A typical single-agent system uses MCP and nothing else.

What MCP Gives You

• A standard way to describe a tool (name, description, JSON schema) that every major provider and agent product understands.
• Discovery: the client lists what the server offers at runtime.
• Two transports: stdio for local subprocess servers, HTTP for shared or remote ones.
• Resources for data the host loads into context, and prompts for reusable templates.
• An ecosystem: servers exist for most common systems, and writing your own is an afternoon.

What MCP does not give you: permissions, budgets, approvals, or any policy. Those stay in your harness. An MCP server is also untrusted code whose descriptions the model reads; treat third-party servers like third-party packages.

What A2A Gives You

• Agent cards: a published description of an agent's capabilities, endpoints, and authentication.
• Task lifecycle: submit, in progress, input required, completed, failed, with streaming updates.
• Message exchange between agents that may run on different infrastructure, owned by different teams or companies.
• Authentication between agents, so one agent's output can be trusted as coming from a known peer.

What A2A does not give you: a reason to have multiple agents. That is the decision to make first.

The Decision

Ask three questions in order.

1. Do I have more than one agent, owned by different parties? If all the "agents" are yours, in one codebase, a subagent is a function call with its own context window. You do not need a network protocol to call a function. Reach for A2A when the other agent is someone else's: another team's, another company's, a vendor's.

2. Does the interaction need a task lifecycle? A2A shines when the delegated task is long-running, may need more input partway, and produces intermediate updates. If the interaction is request-response, an HTTP endpoint is simpler.

3. Is the boundary a trust boundary? If the other agent must authenticate and you must treat its output as untrusted input, A2A's identity model earns its place. Inside one trust domain, it is overhead.

Three no's means MCP only. Three yes's means both.

Architectures

Single agent, many tools (most products). Harness in the middle with policy; MCP servers below it for each system. Subagents, if any, are in-process.

Several agents, one organization. Same as above; "agents" are subagents or services behind ordinary APIs. A2A adds little.

Agents across organizations. Your agent, with its MCP tools, publishes an agent card. A partner's agent discovers it and delegates tasks. Each side's harness treats the other's messages as untrusted input and gates side effects. This is where A2A is designed to live.

The Protocols You Can Ignore For Now

• UI streaming protocols (AG-UI and similar) standardize how an agent's state streams to a front end. Relevant if you are building the chat interface itself.
• Payment and commerce protocols let agents transact. Watch; do not build on yet unless your product is the transaction.
• Older agent communication proposals are converging or fading. If it is not MCP or A2A, check whether it has real adoption before committing.

A Warning About Multi-Agent Systems

The pull toward "a team of specialized agents" is strong and usually wrong for a first version. Multiple agents multiply the surfaces where context is lost, errors cascade, and cost accrues, and they make evaluation much harder because there are more trajectories. Most agent-assisted tasks are better served by one agent with a well-scoped tool set and good context. Add agents when you have a measured reason: a task that is cleanly separable, a trust boundary, or a party you do not control.

What to Practice Next

Draw your system with the harness as a box around the model and your tools below it as MCP servers. If you cannot point to an agent owned by someone else, delete A2A from the diagram. The module mcp-and-agent-protocols-building-tool-servers covers building and consuming MCP servers in depth.