MCP vs A2A: which protocol does what in an agent stack
MCP connects a model to its own tools; A2A connects independent agents to each other. A plain-language comparison of the two standards — layers, primitives, transports — and why a B2B agent usually needs both.
Last updated:
Two open standards get named in almost every conversation about production AI agents, and they are constantly confused with each other: the Model Context Protocol (MCP) and the A2A Protocol. The confusion is understandable — both are "protocols for agents", both arrived within months of each other, and both are backed by major AI vendors. But they solve different problems at different layers, and most real systems need both.
The shortest version:
- MCP is inward. It standardises how a model reaches its own tools and data — the CRM, the database, the file store behind it.
- A2A is outward. It standardises how an agent talks to other agents — ones built by different teams, on different frameworks, owned by different companies.
A useful mental model: MCP is how an agent uses its hands. A2A is how it talks to strangers.
Where each came from
MCP was introduced by Anthropic in November 2024 as an open standard for connecting AI applications to external tools and data sources. Before it, every model-to-tool pairing needed a bespoke adapter, and the integration matrix grew multiplicatively. MCP inverts that: a tool exposes one MCP server, and any MCP-capable client can use it.
The Agent2Agent (A2A) Protocol was announced by Google in April 2025 and later contributed to the Linux Foundation, which now hosts it as a neutral, vendor-independent project. Its premise is that as companies deploy agents, those agents increasingly need to cooperate with agents outside their own vendor ecosystem — and that cooperation needs a common wire format rather than a pile of one-off integrations.
What each protocol actually defines
MCP defines three primitives. Tools are functions the model can invoke. Resources are data the model can read. Prompts are reusable templates a server offers. Transport runs over stdio for local processes or HTTP for remote servers. The mental frame is client–server: one model, reaching out to capabilities it is allowed to use.
A2A defines how an agent publishes an Agent Card describing its capabilities, how another agent initiates a task, and how the two exchange messages and artifacts over standard web transports — HTTP, JSON-RPC, Server-Sent Events. The mental frame is peer-to-peer: two independent parties, discovering each other and holding a structured conversation neither side fully controls.
That last clause is the key architectural difference. An MCP server is yours — you decide what tools your model gets. An A2A counterpart is someone else's agent, which means identity, permissioning, and auditability stop being nice-to-haves and become the core of the design.
"MCP vs A2A" is the wrong frame
The two are complementary, and the pattern you see in practice is an agent speaking both: MCP inward to its own tools, A2A outward to the world. A procurement agent, for example, might use MCP to read its company's requirements documents and write to its evaluation spreadsheet — and A2A-style structured exchange to interview twenty vendors' agents about capabilities, pricing, and compliance.
That outward half is the part B2B software has barely built. Inside one company, agent-to-tool plumbing is a solved problem you can buy. Between companies — where a buyer's agent needs to ask a vendor's agent hard questions and get answers the vendor actually stands behind — there is still almost nothing. This is the layer agent-to-agent commerce names, and it is the layer AgentDoor is built for: a vendor publishes a "door" — a permissioned, auditable endpoint where outside agents can ask questions and get cited answers drawn only from material the vendor approved.
Which one should you care about?
If you are building an agent for internal use: start with MCP; you may never need more. If your product will be evaluated or purchased by other people's agents: the outward layer is the one that determines whether you show up at all. Buyers' agents can only interview vendors that are answerable — and today, almost no vendor is.
We are opening that layer at the end of August 2026. If you want your company to be answerable when buyer agents come knocking, join the waitlist and we will contact you at launch.