A2A vs MCP: what each agent protocol is for
MCP connects an agent to its tools and data. A2A connects one agent to another. What each protocol does, where they overlap, and when you need both.
MCP and A2A solve two different problems, and most teams need MCP first. The Model Context Protocol (MCP) connects one agent to the tools and data it works with: a repository, a mailbox, a database. The Agent2Agent protocol (A2A) connects one agent to another agent, so that work can be handed across a boundary to a worker you do not run. The A2A project's own documentation draws the same line: A2A "connects the agents to each other", and MCP connects each agent to its own tools. Neither replaces the other, and both are now governed by the same foundation.
Where did each protocol come from?
Anthropic released MCP on 25 November 2024 as a standard way for an assistant to reach the systems where data lives. Google announced A2A on 9 April 2025 with more than 50 technology partners, and described it from the first day as complementing MCP rather than competing with it.
Both left their creators within about a year. The Linux Foundation took on A2A as a project in June 2025, and IBM's Agent Communication Protocol merged into it that August. In December 2025 the Linux Foundation formed the Agentic AI Foundation with MCP, Block's goose and OpenAI's AGENTS.md as its first projects, and with more than 10,000 MCP servers already published. A2A joined that foundation in August 2026, with over 150 organisations backing it.
What does MCP do?
MCP gives an agent a uniform way to discover and call capabilities on a server. A server offers three kinds of thing: tools the agent can call, resources it can read, and prompts it can use as templates. An MCP server for GitHub exposes tools such as "list pull requests" and "read file". The agent finds out what they do by reading their descriptions, and calls them with structured arguments.
The protocol has changed a lot in its two years. The current specification, dated 28 July 2026, is the fifth release. It made the protocol stateless and removed the opening handshake. It also deprecated sampling, roots and logging, so older explainers that list sampling as a core feature are now out of date. Authorization is built on OAuth 2.1, and a server must not pass through tokens issued for anything else.
What MCP assumes is that the server is a tool. It answers a call and returns a result. It has no goals of its own, and it does not negotiate.
What does A2A do?
A2A assumes the other side is an agent: something that can take a task, work on it for minutes or days, ask a question back, and return a result when it is ready. The specification reached version 1.0 in March 2026 and is built around a few objects:
- Agent Card. A JSON document an agent publishes to say what it can do, where to reach it, and which authentication it accepts. Version 1.0 lets the card carry a signature.
- Task. The unit of work, with a lifecycle: submitted, working, input required, auth required, completed, failed, canceled or rejected.
- Message and Artifact. Messages carry the conversation about a task. Artifacts are what the task produces.
- Streaming and push notifications. A long task can report progress as it goes, or call a webhook when it finishes.
It runs over JSON-RPC, gRPC or plain HTTP, and supports API keys, OAuth 2.0, OpenID Connect and mutual TLS.
What is the difference, side by side?
| MCP | A2A | |
|---|---|---|
| Connects | An agent to a tool or data source | An agent to another agent |
| The other side is | A server that answers calls | A worker that owns a task |
| Unit of work | One tool call | A task with a lifecycle |
| Long-running work | Optional tasks extension | Built in, with streaming and webhooks |
| Discovery | The server lists its tools | The agent publishes an Agent Card |
| Governance | Agentic AI Foundation | Agentic AI Foundation |
The A2A documentation illustrates the split with a car repair shop. A customer talks to the shop's manager agent over A2A. The manager hands the job to a mechanic agent over A2A. The mechanic drives the diagnostic scanner and the repair manual through MCP, then orders parts from a supplier's agent over A2A. The tools are reached through MCP. Each handover between agents uses A2A.
Where do they overlap?
At the edges, and the edge is moving. An A2A agent can expose a simple, stateless skill as an MCP tool, which lets any MCP client call it. You lose the task lifecycle when you do. MCP has also moved towards longer work with its tasks extension. In practice the question to ask is whether the other side has a lifecycle you need to follow. If it returns an answer, treat it as a tool. If it takes on a job and reports back, treat it as an agent.
What are the security risks of each?
Each protocol makes the other side trustworthy by assumption, and that is where the attacks land.
On MCP the known attack is tool poisoning: instructions hidden in a tool's description, which the agent reads and the user never sees. Invariant Labs disclosed it in April 2025, along with variants where a description changes after it was approved.
On A2A, Palo Alto Networks' Unit 42 described agent session smuggling in October 2025: a malicious remote agent uses a multi-turn session to slip instructions to the agent that called it. Unit 42 was clear that this is not a flaw in the protocol. It exploits the trust one agent places in another. Their advice was signed Agent Cards, human confirmation for high-impact actions, and showing the user what the remote agent did.
The defence is the same in both cases. Do not decide trust by what the other side says about itself. Put a control between the agent and anything that matters, so that a successful injection can attempt an action but cannot complete it.
Do you need both?
Most teams need MCP now and A2A later, if at all.
Start with MCP if your agents do work inside your own systems: reading code, filing tickets, drafting documents. That is where nearly every team begins, and it is where access control decides what an agent can reach. Add A2A when work crosses a boundary between agents you do not control, such as a vendor's agent taking a job from yours. At that point you need a task lifecycle and a way to check who is on the other end, which MCP was never designed to give you.
Cognibl is built on MCP alone. Every tool an agent reaches goes through an existing MCP server, behind a gateway that holds the credential, checks a policy on every call and writes the trace. From the agent's side, Cognibl is one MCP endpoint and a key. A2A is not part of the product today. When work does cross between agents, the record of what was agreed and what was delivered still has to live somewhere, and that is the proof of work attached to the task. See the MCP tools your agents can use.
Keep reading
- The Anthropic IPO: what the filing says for teams that use ClaudeAnthropic filed its public S-1 on 26 October 2026. When it may list, what the filing discloses, and what it means for teams whose work runs on Claude.
- How to stop an AI agent from running up your billAgent costs grow with every turn, and a failed run can cost what a good one does. Where to put a spend cap, why it should be a hard stop, and what to check.
- The best task tracker in 2026 for teams using AI agentsNine task trackers compared on price, free plans, AI agents as assignees, and whether a task can need evidence before done. Which one suits which team.