MCP vs A2A: Two Agent Protocols Compared

MCP and A2A are not rivals. MCP connects one agent to its tools, data and prompts. A2A connects separate agents to each other so they can delegate work and share results. If you are building one agent that calls services, you need MCP and probably not A2A. If you are wiring up agents built by different teams or vendors, A2A is the layer for that, and each of those agents still uses MCP for its own tools. Checked 31 October 2026.

The short version

What each one is

MCP

The Model Context Protocol is "an open-source standard for connecting AI applications to external systems": data sources, tools and workflows. An MCP host creates one client per server, each with its own connection, using JSON-RPC 2.0 over stdio (local) or Streamable HTTP (remote). Servers expose tools, resources and prompts. Assistants such as Claude and ChatGPT and tools such as Visual Studio Code and Cursor support it. The current spec version listed is 2026-07-28.

A2A

The Agent2Agent protocol is, in its own words, "an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems." Agents may be built with different frameworks, languages or vendors, and the docs name LangGraph, CrewAI and Semantic Kernel as examples. A2A gives them a common interaction model.

Its main parts, from the spec:

• Agent Card: a JSON metadata document an A2A server publishes, describing its identity, capabilities, skills, service endpoint and authentication requirements. It is how one agent discovers another.
• Task: the fundamental unit of work, identified by a unique ID. Tasks are stateful and move through a defined lifecycle.
• Message: what the client and agent exchange.
• Part and Artifact: the content pieces, and the outputs (a document, an image, structured data) produced as a result of a task.
• Streaming and push notifications: real-time incremental updates, or asynchronous server-to-webhook updates for long-running or disconnected work.

Operations include send message, send streaming message, get task, list tasks, cancel task and get agent card. Bindings are defined for JSON-RPC, gRPC and HTTP/REST, with room for custom ones. The design goals include reusing existing standards (HTTP, JSON-RPC 2.0, Server-Sent Events) and "opaque execution": agents collaborate on declared capabilities without sharing internal plans, memory or tool implementations.

The one-line difference

The A2A project's own page puts it as direction. MCP is vertical: it deepens a single agent, because every connection hands the agent another tool, resource or skill. A2A is horizontal: it connects agents across a boundary, whether to another team, another department or a partner organization. Used together, it says, "MCP gives each agent depth, and A2A gives your system reach."

Side-by-side facts

How they differ in practice

Who is on the other end

An MCP server is a capability provider. You call search_issues with arguments, you get a result. The server does not decide what you meant.

An A2A server is another agent. You send it a message such as "plan the migration for our billing tables," and it may reply right away or open a task, work for a while, stream status updates, ask you a question and return an artifact. It decides how to do the work, and that process stays opaque to you.

That is why A2A has a task lifecycle and an Agent Card, and MCP has tool schemas.

State and time

MCP calls are mostly short. The spec lists an extension for long-running operations, with polling, mid-flight input and durable handles, which shows the need exists, but the core of MCP is request and response.

A2A treats time as normal. A send-message call can return a task and continue asynchronously, and the protocol includes streaming updates, push notifications to a client webhook and cancelation.

Discovery

An MCP client connects to a server you configured, then lists its tools. You choose which servers exist.

An A2A client reads an Agent Card to learn another agent's skills, endpoint and authentication needs. The model is meant for agents to find and evaluate each other across organizations, which is why authentication requirements sit in the card.

Privacy boundaries

A2A is built so agents can cooperate without exposing internals. The spec's phrase is that they collaborate "without needing to share their internal thoughts, plans, or tool implementations." MCP assumes the client trusts the server enough to run its tools, and its spec puts the consent burden on the host: users must consent to data access and tool calls.

Security notes

The MCP spec is direct that tools represent arbitrary code execution and that descriptions of tool behavior should be treated as untrusted unless they come from a trusted server. Hosts must get explicit user consent before invoking tools.

A2A moves trust to a new place: another organization's agent. Authentication requirements live in the Agent Card, and the spec describes error types such as task-not-found errors where a task ID does not exist or is not accessible. Treat a remote agent as an external party. Decide what data you send it, log what it returns, and do not pass it credentials meant for your own tools.

Neither protocol makes an unsafe design safe. The A2A specification defines API key, HTTP auth, OAuth 2.0, OpenID Connect and mutual TLS security schemes, requires servers to reject requests with invalid or missing credentials, and requires them to return only the tasks visible to the authenticated client. We did not read its protocol security section on transport, so read it before you expose an agent.

When you need A2A

• You operate several agents owned by different teams, and they must hand off work.
• A partner or vendor offers an agent you want to delegate to.
• A task runs long enough to need status, cancelation and callbacks.
• You want to publish your agent so others can discover it.

When you do not

• You have one agent with tools. MCP, or direct API calls, covers it.
• Your "agents" are steps inside one application. A framework's own handoff features, or plain function calls, are simpler and cheaper to debug.
• You have no second organization and no long-running remote work.

Most teams today will use MCP long before they need A2A. The protocol exists for a larger ecosystem than many single-company projects.

Using both

A realistic picture: a planning agent receives a request from a user. It uses MCP to read the ticket system and the code host. It sees that a security review is needed and sends an A2A message to a security agent run by another team. That agent uses its own MCP servers (a scanner, an internal database) to do the review, streams progress back, and returns a report as an artifact. The planning agent never sees the security team's tools, and the security team never sees the planner's prompts.

The A2A project's site describes a related combination in one line: an open standard that lets users "connect agents to tools and data through MCP, and to other agents through A2A."

A closer look at an A2A exchange

Walking through one exchange makes the difference concrete.

1. Discover. The client fetches the remote agent's Agent Card and reads its skills, endpoint and authentication requirements.
2. Send. The client sends a message. The agent either answers with a direct message, for a simple request, or returns a task with an ID.
3. Follow. For a task, the client can call get task to check status, subscribe to streamed status and artifact updates, or register a webhook for push notifications.
4. Receive. The agent returns artifacts, composed of parts, when the work is done.
5. Cancel or list. The client can cancel a task or list tasks it knows about.

An MCP exchange is shorter: initialize, list tools, call a tool, read the result. Both rely on a capability negotiation step and on JSON-RPC style messages. The A2A flow adds identity and state because the other side is a peer, not a function.

Maturity and what to watch

Both protocols are open and versioned. MCP's site shows spec version 2026-07-28 as the latest, and A2A's spec describes a deprecation policy in which a deprecated name should not be removed before the next major version after its replacement arrives. That is a sign of attention to stability, which matters if you plan to build on either. Check the version your client and server support before you integrate, and pin it in your notes.

Choosing

Choose MCP when:

• You are giving an agent access to systems.
• You want the same connection to work across several AI apps.

Choose A2A when:

• Independent agents must cooperate across a boundary.
• You need task state, streaming and callbacks.

Choose both when:

• You are building a system of agents that each have their own tools.

Common mistakes

• Using A2A for in-app steps. If both "agents" run in one process, a function call is simpler, faster and easier to test.
• Using MCP as an agent bus. An MCP tool that secretly runs a long reasoning loop hides state from the caller. If the work has a lifecycle, model it as a task.
• Skipping the trust decision. A remote agent is a third party. Decide what it may see before you connect.
• Adopting both on day one. Get one agent working with two or three servers first.

A short checklist

• Is the counterparty a function or an agent?
• Does the work take longer than one request?
• Do you cross a team or company boundary?
• Have you decided what data a remote agent may receive?
• Do you already have MCP working? Add A2A second.

Four scenarios, and what each needs

The test in every row is the same: is the thing on the other end a function you call, or an agent that decides? Functions are MCP territory. Agents with their own plans and lifecycle are where A2A starts to earn its complexity. If the answer is "an agent, but in my own process," you do not need either protocol, because a framework's handoff feature or a plain function call is enough.

A pilot that costs little

Start small, and put each protocol where it fits.

1. Week one: MCP only. Connect one agent to two or three servers. Check that it calls the right tool and that you can see each call.
2. Week two: pick one handoff. Choose a single task that already crosses a boundary, such as a review step owned by another team.
3. Model it as a task. Write down its states: submitted, working, needs input, done, failed or canceled. If your list does not look like a lifecycle, you may not need A2A for it.
4. Publish an Agent Card or read one. Treat the card as the contract: what skills, what endpoint, what authentication.
5. Decide what the remote agent may see, in writing, before you send it a real message.
6. Run the handoff ten times, including a cancel and a failure, and check that a human can follow each task from start to finish.

What to ask a vendor that offers an A2A agent

• What skills does the Agent Card list, and what does each cost to call?
• Which authentication does the card require, and how are credentials rotated?
• What happens to the content of my messages once the task completes?
• How does the agent report a task it cannot finish?
• Which version of the spec does it implement, and how will it announce a deprecation?

Those questions apply equally to an MCP server run by a third party, with tool descriptions and credentials in place of the card, which is a reason to treat both as vendor integrations and review them the same way.

Questions people ask

Can an MCP tool call an A2A agent? Nothing in the specifications prevents it, but the earlier warning applies: an MCP tool that quietly runs a long reasoning loop hides state from the caller. If the work has a lifecycle, model it as a task.

Do I need A2A to use MCP? No. MCP stands alone and most teams will use it first.

Which is more mature? Both are open and versioned. Check each project's current spec version before you build, since both change.

Our take

From the specs and the A2A project's own comparison, the two are complements, and the question to ask is which side of the agent you are building. Reaching down to tools is MCP. Reaching across to other agents is A2A. Most readers of this page need MCP now and A2A later, if ever.

We did not implement A2A for this page, and our reading of its security model is partial, which we flag above. The MCP and A2A facts come from their official documentation, read on 31 October 2026. If you are choosing a stack today, start with a single agent and a short list of trusted MCP servers, and let a real cross-team need pull A2A in.

Related

• MCP vs API
• MCP vs RAG
• Skills vs MCP servers
• Subagents vs skills
• MCP servers
• How we compare