MCP vs A2A: which agent protocol do you need?

Search for “MCP vs A2A” and you will find a lot of pieces framing it as a fight. It mostly isn’t one. MCP connects an agent to its tools and data. A2A connects agents to each other. One is vertical, one is horizontal, and a system of any size tends to use both at once.

Here is the plain version: what each one does, the code to use it, who supports it, and when you reach for which.

MCP: an agent and its tools

The Model Context Protocol, from Anthropic, gives a model a standard way to call tools, read resources, and use prompts that live behind a server. The agent is the client; the tool provider is the server. There is no built-in discovery — you point a client at a server you already trust and configured.

A tool call looks like this on the client side:

import { Client } from "@modelcontextprotocol/sdk/client/index.js";

const mcp = new Client({ name: "recon-agent", version: "1.0.0" });
await mcp.connect(transport); // stdio or streamable HTTP

const { tools } = await mcp.listTools();
const result = await mcp.callTool({
  name: "port_scan",
  arguments: { host: "example.com", ports: "1-1024" },
});

Who supports it. Anthropic introduced MCP in late 2024 and, in 2025, contributed it to the Agentic AI Foundation under the Linux Foundation. OpenAI added support in 2025 across its Agents SDK, Responses API and the ChatGPT desktop app; Google said Gemini and its SDK would support it; Microsoft, AWS, Cloudflare and GitHub are among the backers. In practice, if your agent runs on a mainstream model today, it can speak MCP.

If you are exposing MCP servers yourself, the hardening matters as much as the wiring — we wrote ten concrete ways to secure MCP servers separately.

A2A: agents talking to agents

The Agent2Agent protocol, started by Google and donated to the Linux Foundation in 2025, solves a different problem: letting one agent delegate work to another agent it does not own or see inside. Unlike an MCP server, an A2A peer is opaque — you send it a task, it does the work however it likes, and you get a result.

A2A agents describe themselves with an Agent Card, a JSON manifest conventionally served at /.well-known/agent-card.json:

{
  "name": "Recon Agent",
  "description": "Maps an external attack surface",
  "url": "https://agents.example.com/recon",
  "version": "1.0.0",
  "capabilities": { "streaming": true },
  "skills": [
    {
      "id": "enumerate",
      "name": "Subdomain enumeration",
      "description": "Finds subdomains for a given apex domain",
      "tags": ["recon"]
    }
  ]
}

That card is the discovery A2A has and MCP does not: another agent can read it, see the skills, and send a task over JSON-RPC:

POST https://agents.example.com/recon
{
  "jsonrpc": "2.0",
  "id": "1",
  "method": "message/send",
  "params": {
    "message": {
      "role": "user",
      "parts": [{ "kind": "text", "text": "Enumerate subdomains for example.com" }]
    }
  }
}

Tasks can be long-running and stateful, which is the point — a peer agent can take minutes, stream progress, and hold its own context instead of dumping everything back into yours.

Who supports it. Google started it; the Linux Foundation reported more than 150 organizations behind it within a year, including the major clouds. IBM’s separate Agent Communication Protocol (ACP) covered the same agent-to-agent ground and, per reporting, is now folding its ideas into A2A rather than competing — so the horizontal layer is consolidating, not splintering. Treat the exact dates and governance details as still moving.

The actual difference

	MCP	A2A
Connects	An agent to its tools and data	An agent to other agents
Direction	Vertical	Horizontal
The other side is	A tool server you control	An opaque peer you don’t
Discovery	None — preconfigure the server	Agent Card at a well-known URL
State	Mostly per-call	Long-running, stateful tasks
Started by	Anthropic	Google

The trap is using one for the other’s job. An MCP server is not a place to coordinate agents — it exposes tools, it does not orchestrate peers. And A2A is overkill for calling a function you wrote and trust; that is what MCP is for.

They stack

In a real setup you use both, at different layers. An orchestrator delegates to specialist agents over A2A, and each specialist reaches its own tools over MCP:

// Horizontal: hand a whole task to a specialist peer over A2A.
const recon = new A2AClient("https://agents.example.com/recon");
const task = await recon.sendMessage("Map the attack surface of example.com");

// Vertical: inside that specialist, reach its tools over MCP.
const nmap = await connectMcp({ command: "node", args: ["nmap-mcp.js"] });
await nmap.callTool({ name: "port_scan", arguments: { host: "example.com" } });

One empirical comparison of agent protocols found MCP tends to do better on simple requests and A2A on complex ones, because handing work to a separate agent keeps each one’s context clean. That matches the rule of thumb: tools go through MCP, teammates go through A2A.

This is also how we think about it in CyberStrike. The thirteen specialist agents — web, cloud, internal network and the rest — each reach their tools through a governed tool layer in the MCP spirit, while the orchestrator hands whole phases between specialists. Splitting the two layers is what lets a narrow agent reason well instead of one agent carrying the entire methodology at once, which is the point we made in how agentic web testing works.

So, which do you need?

• Calling tools and data sources from one agent? MCP.
• Delegating whole tasks to other agents, maybe across vendors? A2A.
• Building anything beyond a single agent with a few tools? Both, layered.

The honest summary: “MCP vs A2A” is the wrong framing. They answer different questions — how an agent uses a tool, and how an agent works with another agent — and the interesting systems being built in 2026 use one inside the other. The layer is still settling, so pin versions, read the specs linked above, and do not bet an architecture on a date from a blog post, this one included.