A2A vs MCP: what each protocol does and when you need both

The short answer to A2A vs MCP is that they solve different problems and most serious agent systems end up using both. The Model Context Protocol (MCP) standardises how an AI application connects a model to tools, data and prompts exposed by a server. The Agent2Agent protocol (A2A) standardises how one agent finds another agent and hands it a task, without either side seeing the other’s prompts, memory or tools.

That distinction matters because the two are often pitched as rivals, and teams waste weeks choosing between them. They sit at different boundaries. MCP is the line between an agent and the things it uses. A2A is the line between an agent and another agent that does work on its behalf, often owned by a different team or company.

This explainer is for engineers and architects deciding how agents in their stack should talk. It compares the two protocols on architecture, authentication, transport and maturity as of October 2026, shows how they compose, and ends with when you need one, the other or both. For a broader map of the frameworks that implement them, see our agent frameworks survey.

A2A vs MCP: the one-paragraph definitions

Before the detail, here is what each specification says it is for, in its own words where possible.

What MCP is

MCP was announced by Anthropic on 25 November 2024 as “an open standard that enables developers to build secure, two-way connections” between data sources and AI-powered tools. The architecture page describes a client-host-server model. The host is the AI application (an IDE, a chat app, an agent runtime). It creates one client per connection, and each client talks to exactly one server. Servers expose three primitives: tools the model can call, resources the application can read, and prompt templates.

The design is deliberately host-centric. One of MCP’s four stated design principles is that “Servers should not be able to read the whole conversation, nor ‘see into’ other servers”. The host keeps the conversation, decides what context to share and enforces consent. A server is meant to be small and focused: a GitHub server, a Postgres server, a filesystem server.

What A2A is

A2A was announced by Google on 9 April 2025 with more than 50 technology partners, as a protocol that “complements Anthropic’s Model Context Protocol (MCP), which provides helpful tools and context to agents.” The v1.0 specification calls it “an open standard designed to facilitate communication and interoperability between independent, potentially opaque AI agent systems.”

The key word is opaque. A2A agents collaborate “without needing to share their internal thoughts, plans, or tool implementations.” The calling side is the A2A client; the agent doing the work is the A2A server, sometimes called the remote agent. The client sends a message, the server creates or updates a task, and the server returns artifacts as outputs. What model the remote agent uses, which tools it calls and how it reasons are not the client’s business.

The A2A project’s own comparison page puts the split in one line: “A2A is about agents partnering on tasks; MCP is more about agents using capabilities.”

Who governs MCP and A2A in October 2026

Both protocols started inside a single company and both now sit under the same neutral body. That matters for anyone betting a platform on them, because it removes the most common objection to adopting either.

MCP. On 9 December 2025 the Linux Foundation announced the Agentic AI Foundation (AAIF), with Anthropic’s MCP, Block’s goose and OpenAI’s AGENTS.md as founding projects. Platinum members are Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. Anthropic’s donation post counted more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript, and stated that “The Model Context Protocol’s governance model will remain unchanged.”

That governance model is documented on the MCP governance page. The project is incorporated as “Model Context Protocol a Series of LF Projects, LLC”, new contributions are licensed under Apache 2.0, and technical decisions follow a hierarchy of contributors, maintainers, core maintainers and lead maintainers. Seats belong to individuals, not companies. Specification changes go through Specification Enhancement Proposals (SEPs). The current lead maintainers are David Soria Parra and Den Delimarsky.

A2A. Google donated A2A to the Linux Foundation, which launched the Agent2Agent project on 23 June 2025 at Open Source Summit North America, with SAP, ServiceNow and Cisco’s Outshift among the early members named in the release. At its first anniversary the Linux Foundation reported more than 150 supporting organisations and production-ready SDKs in five languages (Python, JavaScript, Java, Go and .NET). On 27 August 2026 the project joined the Agentic AI Foundation as a Growth Stage project, alongside MCP, goose and AGENTS.md.

Versions to target

Both projects shipped a breaking release in 2026. MCP’s 2026-07-28 changelog removed protocol-level sessions and the initialize handshake, so “every request now carries its protocol version and client capabilities”, added a mandatory server/discover call, moved long-running tasks into an official extension, and deprecated Roots, Sampling and Logging. A2A’s v1.0 notes renamed operations (message/send became SendMessage), changed enums to forms such as TASK_STATE_COMPLETED, removed the kind discriminator, and made a2a.proto the normative source for every binding. If you built against either protocol in 2025, plan a migration.

Architecture side by side

The fastest way to see the difference is to line up what each protocol treats as the unit of work and who holds state.

Figure 1: MCP is a model-to-tool protocol where the host sees everything; A2A is an agent-to-agent protocol where the remote agent stays a black box.

MCP: the host is in charge

In MCP the host’s model decides to call a tool. The client sends tools/call with a name and arguments, the server runs it and returns content or structuredContent that conforms to an optional outputSchema. The tools specification calls tools “model-controlled” and adds that “there SHOULD always be a human in the loop with the ability to deny tool invocations.”

Since the 2026-07-28 revision, MCP is stateless at the protocol level. Servers that need state across calls, such as a shopping basket or an open browser session, “should do so by returning an explicit handle from a creation tool and accepting that handle as an argument on subsequent calls.” When a server needs more input mid-call, it no longer sends its own request; it returns an InputRequiredResult and the client retries the original call with the answers. That keeps the host in control of every turn.

A2A: the remote agent is in charge

In A2A, the client does not choose tools or see reasoning. It sends a message (made of parts: text, file references or structured data) using SendMessage or SendStreamingMessage. The remote agent decides what to do and reports progress through a task whose state moves through submitted, working, input required, auth required and one of four terminal states: completed, failed, cancelled or rejected. The client can read a task with GetTask, list them with ListTasks, cancel with CancelTask and re-attach to a stream with SubscribeToTask.

Discovery is a document rather than a call. An A2A server publishes an Agent Card, a JSON document that describes its identity, the skills it offers, the interfaces (bindings and URLs) it supports, whether it streams or pushes, and how callers must authenticate. Clients fetch it from https://{server_domain}/.well-known/agent-card.json. An authenticated client can ask for a richer card with GetExtendedAgentCard.

The practical consequence

The visibility difference decides which protocol fits. If you want the calling model to see a tool’s schema and choose arguments, you want MCP. If you want to hand off a goal (“reconcile these invoices”, “book this trip”) to a system you do not control and get back a result, you want A2A. A tool is a function you call; a remote agent is a colleague you brief.

How authentication differs between MCP and A2A

Authentication is where the two specifications look least alike, and where teams most often get the design wrong.

MCP: a defined OAuth 2.1 profile

The MCP Authorization specification starts with a qualifier that surprises people: “Authorization is OPTIONAL for MCP implementations.” When it is used:

• HTTP-based servers SHOULD follow the spec; stdio servers SHOULD NOT and “instead retrieve credentials from the environment.”
• A protected MCP server “acts as an OAuth 2.1 resource server”; the MCP client is the OAuth 2.1 client; the authorisation server may be separate.
• Servers MUST publish OAuth 2.0 Protected Resource Metadata (RFC 9728) so clients can discover the authorisation server.
• Clients register through Client ID Metadata Documents (preferred), pre-registration, or Dynamic Client Registration, which the 2026-07-28 revision deprecated.
• Clients MUST send the resource parameter (RFC 8707) naming the MCP server, and servers MUST validate that tokens were issued for them. “MCP servers MUST NOT accept or transit any other tokens.”
• The latest revision also has clients validate the iss parameter (RFC 9207) to block mix-up attacks.

The spec therefore answers “how does a client get a token for this server?” in detail. What it does not answer is how the MCP server should authenticate to whatever sits behind it, such as the GitHub or Salesforce API. The security best practices cover the traps there: confused-deputy attacks on MCP proxy servers that use a static client ID, token passthrough, SSRF during metadata discovery and over-broad scopes. That upstream hop is where most real MCP deployments need extra machinery.

A2A: declare your schemes, carry credentials in headers

A2A takes a lighter approach. Section 7 of the A2A specification states that “Identity information is handled at the protocol layer, not within A2A semantics.” In practice:

• The Agent Card declares one or more security schemes: API key, HTTP authentication (bearer or basic), OAuth 2.0, OpenID Connect or mutual TLS.
• v1.0 OAuth flows are authorisation code (with a pkce_required flag), client credentials and device code; the implicit and password flows were removed.
• The client “obtains the necessary credentials through an out-of-band process” and sends them “in protocol-appropriate headers or metadata for every A2A request.”
• Mid-task, an agent that needs extra authorisation (for example, the user’s consent to read a mailbox) can move the task to TASK_STATE_AUTH_REQUIRED and let the client fulfil it. The spec warns that agents “MUST NOT treat the TASK_STATE_AUTH_REQUIRED state transition, by itself, as authorization for any particular operation.”
• Agent Cards “MAY be digitally signed using JSON Web Signature (JWS)”, after canonicalisation with RFC 8785, so a client can check who published a card and that it was not altered.
• Production deployments must use HTTPS or TLS, with TLS 1.3 recommended.

What that means for builders

MCP is opinionated about the client-to-server hop because MCP clients are often desktop apps and IDEs that need a standard way to log a user in to an arbitrary server. A2A assumes the parties are services that already know how to authenticate to each other, so it standardises the declaration, not the dance.

Neither protocol solves delegation end to end. When an A2A agent calls MCP tools on behalf of the original user, you have to decide whether the tools see the user’s identity, the agent’s service identity or both. Neither specification carries the original caller’s identity through that chain for you. That is the gap gateways and identity providers are filling, discussed below.

Transport, streaming and long-running work

Both protocols reuse web plumbing rather than inventing their own, but they make different choices about how long a piece of work is expected to last.

MCP transports. The transports page defines two standard bindings. stdio runs the server as a subprocess and exchanges newline-delimited JSON-RPC over standard input and output, which is how most local servers in IDEs work. Streamable HTTP sends each message as an HTTP POST to a single MCP endpoint, with replies as a JSON object or a request-scoped Server-Sent Events stream. The old HTTP+SSE transport is formally deprecated, and the 2026-07-28 revision removed SSE resumability, so a broken stream means re-issuing the request. Change notifications, such as a server’s tool list changing, now arrive on a single subscriptions/listen stream.

A2A bindings. A2A defines three bindings, all generated from the same a2a.proto: JSON-RPC over HTTP, gRPC, and HTTP+JSON (REST). Streaming uses Server-Sent Events and requires the Agent Card to declare capabilities.streaming. For work that takes hours, A2A adds push notifications: “Asynchronous task updates delivered via server-initiated HTTP POST requests to a client-provided webhook URL.” Clients manage those webhooks with four push-configuration operations. A v1.0 addition, multi-tenancy, lets one endpoint serve several agents by carrying a tenant field on requests.

Long-running work. This is the clearest functional difference. A2A was designed from the start for tasks that run “from quick requests to long-running work that may involve humans over hours or days”, in Google’s launch wording. MCP tool calls are expected to finish within a request; MCP’s answer for long work is the optional io.modelcontextprotocol/tasks extension, which supports polling with tasks/get and client input with tasks/update. If your design needs hours-long jobs with webhook callbacks and a human approving a step halfway through, A2A’s task model gives you that by default.

Maturity and adoption as of October 2026

MCP is the more widely deployed protocol by a large margin. A2A is younger and its adoption is concentrated in enterprise platforms and agent frameworks rather than end-user apps.

MCP. The 10,000-plus public servers and 97 million monthly SDK downloads cited at the AAIF launch are the best public numbers. The Linux Foundation’s announcement listed Claude, Cursor, Microsoft Copilot, Gemini, VS Code and ChatGPT among the products that support it. Practically every agent framework is an MCP client; our ranking of agent orchestration frameworks found MCP client support in all ten. For the server side, see our guide to the most useful MCP servers.

A2A. The A2A project’s August announcement names native support in Google Cloud, Amazon Bedrock AgentCore Runtime and Microsoft’s Azure AI Foundry, enterprise use by ServiceNow, Salesforce, Atlassian and SAP, and framework support in LangGraph, CrewAI, Pydantic AI, AG2 and IBM BeeAI. AWS’s AgentCore documentation shows what native support means in practice: A2A containers listen on port 9000 at the root path, serve their Agent Card at the well-known path, and gain SigV4 or OAuth 2.0 authentication from the platform.

The same AWS page is also a useful warning about version drift. Its sample client sends "method": "message/send" with kind fields on parts, which are v0.3 names that v1.0 replaced. Platforms and SDKs are moving at different speeds, and our comparison of managed agent platforms found some documenting A2A v1.0, others v0.3, and at least one listing it as preview. Test the specific version pair between your client and each remote agent, not just the protocol name. The A2A-Version header exists for exactly this, and servers that do not support a requested version return VersionNotSupportedError.

How MCP and A2A compose in one system

The cleanest way to think about composition is the A2A project’s own image: “A2A connects the agents to each other; MCP connects each agent to its own tools.” Its worked example is an auto repair shop. A customer talks to a shop-manager agent over A2A. A mechanic agent uses MCP to drive its diagnostic scanner, repair-manual database and lift. When it needs a part, the mechanic uses A2A to ask a parts-supplier agent, run by another company, about stock.

A worked enterprise example

Take a travel-booking assistant in a mid-sized company. The user talks to a planner agent inside the company’s chat app.

1. The planner uses MCP to call the company’s calendar and HR policy servers. It needs to see their schemas and choose arguments, so MCP is the right fit.
2. The planner reads the Agent Card of a travel agency’s booking agent, run by an outside supplier, and sends it a message with SendStreamingMessage: dates, budget, policy limits.
3. The booking agent creates a task, streams status updates, and uses its own MCP servers (flight and hotel inventory, payments) that the planner never sees.
4. Halfway through, the booking agent needs the traveller to approve a fare above policy. It moves the task to TASK_STATE_INPUT_REQUIRED. The planner surfaces the question; the user answers; the planner sends a follow-up message on the same task.
5. The booking agent completes the task and returns an artifact: the itinerary and booking references. The planner uses MCP once more to write it to the calendar.

Figure 2: A2A carries the task across the organisational boundary; MCP sits inside each agent, and neither side sees the other’s tools.

The boundary matters more than the protocols. Inside the planner, everything the model touches is a tool. Across the line to the supplier, the planner gets a task with states and artifacts and nothing more. If both agents were in the same codebase and owned by the same team, you could skip A2A and call the booking logic as an MCP tool or a plain function.

The “agent as a tool” shortcut

A common question is whether you can expose an agent through MCP instead and skip A2A. The A2A documentation says an A2A server “can expose some skills as MCP-compatible resources”, but only when the skill is well defined and can be called in a stateless, tool-like way. Wrapping an agent as an MCP tool loses task state, INPUT_REQUIRED turns, streaming progress, push notifications and the opacity that lets two organisations collaborate without sharing internals. Use the shortcut for a lookup (“summarise this ticket”), not for delegation (“handle this refund”).

Tracing work across both protocols

Composition creates an observability problem: one user request becomes an A2A task in one system and a dozen MCP tool calls and model calls in another. A2A’s contextId groups related tasks and messages into one conversation, and task IDs identify units of work. MCP’s 2026-07-28 revision documents OpenTelemetry trace context in _meta (traceparent, tracestate, baggage). Neither protocol joins the two automatically. Something has to copy the A2A context and task IDs onto the model and MCP calls made for that task, and somewhere has to store them together.

Where a gateway sits on each protocol

That joining job is one reason gateways have moved into agent traffic. An MCP gateway sits between agents and MCP servers and decides which tools each caller can see, holds upstream credentials and logs calls; we covered the pattern in our MCP gateway explainer and compared products in the top MCP gateways for 2026. An A2A-aware gateway does the equivalent for agents: it sits in front of registered agents, checks which callers may reach which agent, and records tasks.

Bifrost on the MCP side

Bifrost, an open-source AI gateway written in Go by Maxim AI, is a useful worked example because its documentation now covers both sides. On the MCP side, the MCP overview describes it as both an MCP client, connecting to servers over stdio, HTTP or SSE, and an MCP server, exposing the aggregated tools on one endpoint to hosts such as Claude Desktop and Cursor. The governance controls are the ones the MCP spec leaves to implementers:

• Tool allow-lists per caller. MCP tool filtering is deny-by-default: a virtual key with no MCP configuration gets no tools unless a server is marked allow-by-default, and the allow-list is enforced again at execution time.
• Curated endpoints. Virtual MCPs bundle chosen tools from several servers behind a stable /mcp/<slug> URL that only attached keys can reach.
• Upstream authentication. The MCP auth modes are none, static headers, admin OAuth 2.0, per-user OAuth, per-user headers and token exchange, which addresses the upstream-credential gap described above.
• Explicit execution. By default the gateway does not run tool calls a model suggests; the application calls a separate execute endpoint, and auto-execution must be opted into.

For the governance angle in more depth, the vendor’s MCP gateway page summarises the tool-access and cost controls. Bifrost’s published benchmark reports 11 µs of added overhead per request at 5,000 RPS on an AWS t3.xlarge, which is relevant when a single user request fans out into many gateway hops.

Bifrost on the A2A side

The A2A side is new. Bifrost’s v2.3.0 release, tagged on 13 October 2026, added an Agent Gateway that proxies A2A agents. According to the Agent Gateway documentation:

• An agent is registered by its Agent Card URL. Bifrost fetches and validates the A2A v1 card and serves its own card, JSON-RPC and REST endpoints for that agent under /agents/a2a/<name>/, with an optional shared gRPC listener. Client-facing and agent-facing transports can differ.
• Access is granted per virtual key, and the docs are explicit that “an agent grant alone does not authorize the agent’s later LLM or MCP calls”. Calling an agent and using its tools are separate permissions.
• Authentication is configured at each boundary: card fetch, requests to the agent (headers or OAuth 2.0 client credentials, chosen from the card’s requirements), and an opt-in to forward the caller’s Bifrost credential so the agent’s own model and tool calls are attributed to the original caller. By default the gateway strips that credential before forwarding.
• Push notifications go through a gateway callback with a per-configuration token and a retried outbox.
• To join the two protocols in the logs, the agent sends x-bf-session-id (the A2A context ID) and x-bf-agent-correlation-id (the task ID) on its model and MCP requests, and Agent Logs then link a session and task to the LLM and MCP calls made for it.

That last point is the composition problem from the previous section, solved with two headers. Enterprise deployments add agent grants through access profiles and projects, user attribution and scoped log access; as with the rest of the product, advanced controls such as SSO, RBAC, audit logs, guardrails and clustering come with the enterprise tier. For the wider product, see the Bifrost overview.

Other approaches

Bifrost is not the only gateway to handle both. LiteLLM’s A2A support registers A2A agents on its proxy, lets clients invoke them through the A2A SDK or an OpenAI-compatible endpoint with an a2a/ model prefix, checks whether “the calling key (and its team) is allowed to invoke the requested agent,” and attributes cost per agent. AWS’s AgentCore Runtime hosts A2A servers and adds SigV4 or OAuth 2.0 authentication in front of them. IBM’s open-source ContextForge describes itself as a registry and proxy that “federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability.” The common thread is that teams want one place to answer “who called which agent, which tools did that agent use, and on whose behalf”.

When you need MCP, A2A or both

Most teams can answer the question with four checks, in this order.

Figure 3: Pick the protocol by the boundary and the length of the work, not by which one is newer.

You only need MCP

Your agent is one process, owned by one team, and it needs to reach databases, APIs, files and SaaS tools. The model should see each tool’s schema and choose arguments. This covers coding agents, internal assistants and most single-agent products. Multi-agent designs inside one framework (a supervisor and sub-agents in LangGraph, a crew in CrewAI) usually do not need A2A between their own agents either; the framework’s own handoff is simpler and faster.

You need A2A

The work crosses a boundary you do not control: another team’s agent with its own release cycle, a supplier’s agent, or a platform agent such as one hosted in Salesforce or ServiceNow. You want to delegate a goal, track it as a task, possibly wait hours, and get back artifacts without seeing the other side’s tools. A2A also fits when agents are built in different frameworks or languages and need a neutral contract.

You need both

Almost every system that uses A2A. Each agent still needs tools, and those tools are best reached over MCP. The design work is deciding where the agent boundaries sit, then standardising identity propagation and trace correlation across them.

You need a gateway as well

Several teams share the same MCP servers or the same agents; you need per-caller tool and agent permissions, central credentials for upstream systems, cost attribution, and logs that tie a task to the calls inside it. That is a governance requirement, not a protocol one, and it applies to both sides.

Limits and counter-arguments worth taking seriously

Neither protocol is finished, and the case for adopting A2A in particular deserves some scepticism.

A2A may be more than you need. Much of what is called multi-agent today runs in one process under one framework. Adding A2A between components you own adds network hops, Agent Cards, versioning and authentication with little benefit. The protocol earns its cost at organisational or platform boundaries.

Adoption claims are counts of supporters, not traffic. “150+ organisations” measures who backs the project, not how many production calls cross it. The A2A blog says the protocol runs in production in supply chains, financial services and mobile platforms, but no public figure for A2A traffic exists. MCP’s server and download counts are stronger evidence of use, though they also count hobby servers.

Overlap is growing. MCP’s tasks extension, multi round-trip requests and elicitation give MCP some of the long-running, interactive behaviour that used to be A2A’s alone. Expect a grey zone where either could work; let the visibility question (should the caller see the internals?) decide.

Security is not solved by either spec. MCP’s best-practice guide spends most of its length on attacks that come from implementations: confused deputies, token passthrough, SSRF and malicious local servers. A2A’s signed Agent Cards prove who published a card, not that the agent behind it is safe. Prompt injection travels across both: a malicious artifact from a remote agent, or a malicious tool result, lands in your model’s context either way.

Version churn is real. Both projects shipped breaking changes in 2026, and SDKs and platforms lag. Budget for upgrades, pin versions, and test each client-server pair.

What to do next

Treat MCP and A2A as two layers of one design rather than two options:

1. Draw your boundaries first. List the agents you have or plan, who owns each, and which ones cross a team or company line. Only those crossings need A2A.
2. Standardise tools on MCP now. It is the more mature protocol and the one every framework speaks. Target the 2026-07-28 revision for new servers and read the changelog before upgrading old ones.
3. Pilot A2A at one real boundary. Pick a single delegation, such as a platform agent or a partner’s agent, implement v1.0 with signed Agent Cards, and test version negotiation explicitly.
4. Decide how identity flows. Write down whether downstream tools see the end user, the calling agent or both, and enforce it, rather than letting each agent invent its own answer.
5. Correlate traces across protocols. Carry A2A context and task IDs onto every model and MCP call made for a task, whether through OpenTelemetry, gateway headers or both.
6. Put policy in one place once you share. When a second team starts calling the same tools or agents, move permissions, upstream credentials and logs into a gateway that covers both protocols.

We think the “A2A vs MCP” framing will fade within a year, the way nobody asks whether to use HTTP or SQL. MCP is how an agent reaches the things it uses; A2A is how it works with other agents. The decisions that matter are where you draw the agent boundaries and how you govern what crosses them.