Skip to content
Short answer: In the A2A vs MCP question, the two protocols do different jobs and are not rivals. MCP (Model Context Protocol) connects one AI agent to tools and data, such as a database or a browser. A2A (Agent2Agent) connects one agent to another agent so they can work on a task together. The A2A project says so itself: “The Model Context Protocol (MCP) and the A2A Protocol are not competitors.”
If you build with a single agent, you will meet MCP first and may never need A2A. If you build several agents that must talk to each other across teams or vendors, A2A starts to matter. New to MCP? Read what MCP servers are first, or browse the Klyvoo MCP servers directory to see real examples.
A2A vs MCP at a glance
| MCP | A2A | |
|---|---|---|
| Full name | Model Context Protocol | Agent2Agent Protocol |
| Connects | An AI app to tools, data and prompts | One agent to another agent |
| Direction | Vertical: gives one agent more depth | Horizontal: links agents across boundaries |
| Other side is | A server that exposes tools, resources and prompts | A remote agent that keeps its inner workings private |
| Message format | JSON-RPC 2.0 | Defined over JSON-RPC, gRPC or HTTP+JSON |
| Discovery | A server describes its capabilities on request | An Agent Card at a well-known URL |
| Unit of work | A tool call | A task with a life cycle |
| Governance | Open source standard at modelcontextprotocol.io | Open standard under the Linux Foundation |
What is MCP?
MCP is an open standard for connecting AI applications to outside systems. Think of it as a plug between an AI app and the things it needs to reach.
The setup has three parts. The host is the AI application, such as Claude Code or Visual Studio Code. The host creates one client for each server it connects to. The server is the program that provides context: your files, your issue tracker, a search engine.
A server can offer three things. Tools are functions the AI can run. Resources are data it can read. Prompts are reusable templates. Messages travel as JSON-RPC 2.0, over stdio for a server on your own machine or over Streamable HTTP for a remote one.
Most of what people call “MCP servers” are mostly tools. Our MCP vs API post explains why a standard plug beats wiring every API by hand. For the commands to connect one, see how to add MCP servers to Claude Code.
What is A2A?
A2A is an open protocol that lets agents talk to each other, whatever framework or vendor built them. The project describes it as “an open protocol enabling communication and interoperability between opaque agentic applications.” Google originally developed it and donated it to the Linux Foundation, and a Technical Steering Committee maintains it.
The word “opaque” matters. One A2A agent does not have to reveal its internal logic, memory or tools to another. The project lists “Opaque Execution” as a design principle: agents collaborate through declared capabilities only. That makes it workable between companies that do not want to share their internals.
These are the pieces to know:
- Agent Card. A metadata file a server publishes so other agents can find out what it can do, where to reach it and how to authenticate.
- Message. What the calling agent sends to start or continue the conversation.
- Task. The unit of work the remote agent creates. It moves through states. The specification lists submitted, working, input-required and auth-required, then the end states completed, failed, canceled and rejected.
- Artifact. An output a task produces.
A2A builds on web standards: HTTP, JSON-RPC and Server-Sent Events. The latest released specification is version 1.0.0. It defines bindings for JSON-RPC, gRPC and HTTP+JSON. SDKs exist for Python, JavaScript, Java, C#, Go and Rust.
How do A2A and MCP differ?
Tool use versus teamwork
The A2A project puts it this way: MCP is vertical and A2A is horizontal. MCP deepens a single agent by connecting it to more tools, resources or skills. A2A connects agents across boundaries, such as different teams, departments or partner organizations.
Its summary is short: “A2A is about agents partnering on tasks; MCP is more about agents using capabilities.”
Tools are specific, agents are open-ended
An MCP tool is typically a structured, specific call. The A2A documentation says such tools are often stateless. You ask for the weather in a city and get the answer. An A2A agent is described as more autonomous. It can reason, plan, use several tools, keep state over a longer exchange and ask you follow-up questions.
That shows in the life cycle. An A2A task can pause at “input required” while the remote agent waits for you, then carry on. A plain tool call has no such pause. (MCP does have an optional Tasks extension for long-running requests, so the line is not absolute.)
Who can see inside
With MCP you usually know what the server offers: the client lists its tools and reads their descriptions and input schemas. With A2A the other agent is a black box by design. You see its Agent Card and its answers, not how it got there.
Discovery works differently
An MCP client asks a server what it supports. An A2A client fetches the Agent Card, which the project says lives at /.well-known/agent-card.json, and reads the capabilities, endpoint and security schemes from it.
A worked example: the repair shop
The A2A docs use an auto repair shop to show both protocols in one flow:
- A customer tells a “Shop Manager” agent about a rattling noise. This is A2A.
- The Shop Manager asks follow-up questions, such as for a video of the noise. Still A2A, a multi-turn dialogue.
- The mechanic agent uses MCP to reach a diagnostic scanner, a repair manual database and a platform lift. These are tools.
- The mechanic asks a “Parts Supplier” agent whether a part is in stock. This is A2A again, between two separate agents.
The pattern is easy to carry over. A research agent might use MCP to read your files and search the web, then use A2A to hand a sub-question to a specialist agent run by another team. Our multi-agent systems guide covers why teams split work across agents in the first place.
When to use MCP, A2A or both
Use MCP when:
- One agent needs to reach a tool or data source, such as GitHub, a database or a browser.
- You want the same integration to work in many AI apps.
- The job is a clear request with a clear answer.
Use A2A when:
- Two or more agents, built by different teams or vendors, need to hand work to each other.
- The remote agent should keep its internals private.
- The work takes several turns or a long time, and the caller must see progress.
Use both when you run a system of agents. Each agent uses MCP for its own tools and A2A to reach the others. The A2A project describes it as MCP giving each agent depth and A2A giving the system reach.
The two can also meet. The A2A docs say an A2A server can expose some skills as MCP-compatible resources, and that this suits well-defined skills that can be called like a tool. For anything that needs a real back-and-forth, they say A2A is the better fit.
Do frameworks support A2A and MCP?
Support differs by project, so check each one’s docs before you rely on it. As one example, Google’s Agent Development Kit has a page on building multi-agent systems with A2A, with quickstarts for exposing an agent in Python, Go and Java and for consuming one in Python, Go, Java and Kotlin. That page marks A2A as experimental. ADK also has a separate MCP tools section. You can read more on the Google ADK page and in our Google ADK vs LangGraph comparison.
For other options, see the best AI agent frameworks, including LangGraph. We haven’t verified A2A support for each one, so we make no claim about it here.
What neither protocol does
- Neither is an agent. They are the wiring. You still need a model, a framework and good instructions.
- Neither makes an agent trustworthy. MCP leaves it to the host to decide how the model uses context, and A2A leaves each agent to enforce its own rules. Treat any outside server or agent as untrusted until you have checked it.
- Neither replaces the other. Using A2A for a simple database lookup adds weight for no gain. Using MCP to hold a long dialogue between agents is a poor fit.
- Neither removes the need for sign-in. A2A servers declare security schemes such as OAuth 2.0 and API keys, and remote MCP servers recommend OAuth.
FAQ
Is A2A a replacement for MCP?
No. The A2A project says the two are complementary and not competitors. MCP covers agent-to-tool communication and A2A covers agent-to-agent communication.
What is the main difference between A2A and MCP?
MCP connects an AI agent to tools, data and prompts. A2A connects one agent to another so they can work on a task together. One adds depth to a single agent, the other adds reach across a system of agents.
Do I need A2A if I already use MCP?
Only if your agents must talk to other agents, especially ones built by other teams or vendors. A single agent that uses tools through MCP does not need A2A.
Who created A2A and MCP?
The A2A project says Google originally developed A2A and donated it to the Linux Foundation. MCP is an open-source standard documented at modelcontextprotocol.io, and Claude Code and Claude Desktop appear in its docs as example hosts.
Can an MCP server be an A2A agent?
Not directly, because they are different protocols. The A2A docs do say an A2A server can expose some skills as MCP-compatible resources, which works best for simple, tool-like skills.
Which one should a beginner learn first?
Start with MCP. It is how a single agent reaches real tools, and it is where most people begin. Learn A2A once you are building more than one agent.
Ready to try the tool side? Start with the Klyvoo MCP servers directory and pick a server for the job you need done.