A2A vs MCP: how the two agent protocols divide the work

TL;DR

• A2A vs MCP is not a contest. MCP connects one agent to tools, data and prompts; the A2A protocol connects independent agents so they can delegate tasks to each other without exposing their internals.
• Discovery differs in kind: an A2A Agent Card advertises an agent’s skills and auth at /.well-known/agent-card.json, while MCP’s server/discover returns a server’s protocol versions and capabilities, after which tools/list enumerates the tools.
• A2A tasks are stateful by design, with nine defined states including input required and auth required. MCP became fully stateless in its 2026-07-28 revision and moved long-running work into an optional Tasks extension.
• Both protocols now live in the Linux Foundation’s Agentic AI Foundation. Most production systems that use A2A also use MCP, so governance has to cover both the agent-to-agent hop and the tool hop below it.

The Agent2Agent (A2A) protocol and the Model Context Protocol (MCP) are open standards for AI agents that solve different problems: MCP defines how an agent or AI application calls tools and reads data from MCP servers, and A2A defines how one agent discovers another agent, hands it a task and receives the result. The A2A project’s own documentation calls MCP “vertical” and A2A “horizontal”. Read at the level of the specifications (A2A v1.0 and MCP revision 2026-07-28), the A2A vs MCP question resolves into a set of concrete differences in discovery, state, transport and authorization, and into a common architecture in which both run at once.

A2A vs MCP at a glance

A2A and MCP differ in who sits on each end of the connection. MCP links a host application to servers that expose tools, resources and prompts; A2A links a client agent to a remote agent that keeps its tools, memory and reasoning private. The table compares them on the points their specifications define.

The rest of this article takes those rows one at a time, then turns to how the two protocols compose and where a gateway fits.

Figure 1: A2A runs horizontally between opaque agents; MCP runs vertically from one agent down to its tools and data.

What the Model Context Protocol does

MCP is a JSON-RPC protocol through which a host application, such as a coding agent or chat client, connects to MCP servers that expose three kinds of capability: tools the model can call, resources it can read, and prompt templates. Its purpose is to give a single agent standard access to external systems.

The current specification describes three roles: hosts (the LLM applications), clients (connectors inside the host) and servers (the services that provide context and capabilities). It credits the Language Server Protocol as its model. Just as LSP lets any editor support any programming language through one interface, MCP lets any agent use any compliant tool server.

The 2026-07-28 revision changed MCP more than any release since launch. According to the changelog, it:

• removed the initialize handshake and protocol-level sessions, so every request now carries its protocol version and client capabilities in _meta;
• added server/discover, a mandatory method that returns a server’s supported versions, capabilities and identity;
• moved tasks out of the core protocol into an official extension, io.modelcontextprotocol/tasks;
• deprecated the Roots, Sampling and Logging features, and deprecated Dynamic Client Registration in favor of Client ID Metadata Documents.

Statelessness matters for the comparison. MCP’s core is now a set of independent requests. Tools are described by JSON Schema and are meant to be predictable functions. A general explainer on what the Model Context Protocol is covers the primitives in more depth, and a walk through MCP transports, primitives and the message lifecycle traces a request from client to server. For a survey of which servers are worth installing, the Frontier Wire’s ranking of MCP servers compares ten on auth, tools and security.

What the A2A protocol does

A2A is an open protocol for communication between independent AI agents that may be built on different frameworks, by different vendors, and kept opaque to each other. A client agent discovers a remote agent, sends it a message, and the remote agent manages the resulting task until it returns artifacts.

Google announced A2A on 9 April 2025 with more than 50 technology partners, including Atlassian, Box, Cohere, LangChain, MongoDB, PayPal, Salesforce, SAP and ServiceNow. The announcement stated that A2A “complements Anthropic’s Model Context Protocol” and listed five design principles: embrace agentic capabilities, build on existing standards, be secure by default, support long-running tasks and stay modality agnostic.

The v1.0 specification states the goal plainly: agents should collaborate “without needing access to each other’s internal state, memory, or tools.” That principle, which the specification calls opaque execution, is the clearest line between the two protocols. An MCP server exposes its functions for the caller’s model to invoke. An A2A server exposes skills, accepts a goal, and decides for itself how to reach it, possibly by calling its own MCP tools.

The specification is organized in three layers: a canonical data model (Task, Message, AgentCard, Part, Artifact, Extension), abstract operations (send message, stream, get, list and cancel tasks, subscribe, push notification configuration, get extended Agent Card), and protocol bindings. Since v1.0, the file spec/a2a.proto is the single normative definition of every object.

Version 1.0.0 was tagged in the A2A GitHub repository on 12 March 2026, followed by v1.0.1 on 28 May 2026. The v1.0 change log lists breaking changes from v0.3: operations renamed (message/send became SendMessage), enum values moved to SCREAMING_SNAKE_CASE, the kind discriminator removed, and Agent Card fields reorganized. Teams that built on v0.3 SDKs have a migration to plan.

Agent cards and MCP server discovery

Discovery in A2A answers “which agent can do this job, and how do I call it?” through the Agent Card. Discovery in MCP answers “what does this server support?” through server/discover, followed by list calls that enumerate tools and resources. The A2A card describes skills; the MCP response describes capabilities and protocol versions.

The A2A Agent Card

An Agent Card is a JSON metadata document describing an agent’s identity, capabilities, skills, service endpoint and authentication requirements. Section 8.2 of the specification lists three ways to find one:

• a well-known URI, https://{server_domain}/.well-known/agent-card.json, registered with IANA as a permanent entry;
• registries or curated catalogs of agents;
• direct configuration of a card URL or its content.

A v1.0 card declares supportedInterfaces in preference order, each with a URL, a protocol binding (JSON-RPC, gRPC or REST) and a protocol version. It lists skills with IDs and descriptions, default input and output media types, capability flags for streaming and push notifications, and security schemes. An authenticated client can request an extended Agent Card that carries details the public card withholds.

Cards can be signed. Version 1.0 specifies JSON Web Signature (RFC 7515) over a canonical form defined by the JSON Canonicalization Scheme (RFC 8785), so a client can verify that a card was not altered and came from the claimed provider. The specification also says a card “SHOULD NOT include sensitive credentials or internal implementation details.”

MCP server discovery

MCP has no equivalent of a skills document. A client calls server/discover, which every server must implement, and receives supported protocol versions, capabilities such as tools and resources, server identity, optional usage instructions, and caching hints (ttlMs, cacheScope). The client then calls tools/list to get each tool’s name, description and JSON Schema.

For finding servers in the first place, the MCP Registry is the official metadata repository for publicly accessible servers. Its documentation states that it is in preview and that breaking changes or data resets may occur before general availability.

The difference in granularity matters in practice. An Agent Card says, in effect, “this agent can reconcile invoices,” and leaves the method to the agent. An MCP tool list says “here is get_invoice(id) and post_payment(amount, account),” and the calling model decides how to combine them. Frameworks increasingly generate cards automatically: LangChain’s Agent Server, for example, exposes an A2A endpoint and Agent Card for every deployed assistant.

Tasks, state and long-running work

A2A treats every unit of work as a stateful Task that can run for seconds or days, pause for human input and stream partial results. MCP treats a tool call as a request with one result, and handles long-running work only through its optional Tasks extension.

Figure 2: A2A tasks are stateful and can pause for input or authorization; an MCP tool call returns one result unless the Tasks extension is negotiated.

The A2A task lifecycle

As Figure 2 shows, an A2A task moves through defined states. The v1.0 specification lists nine TaskState values:

A client follows progress in one of three ways: polling with GetTask, holding a stream opened by SendStreamingMessage (and reattaching with SubscribeToTask), or registering a webhook for push notifications. Related tasks share a contextId, which is how multi-turn conversations between agents are tracked. Outputs arrive as artifacts made of parts, which can carry text, file references or structured data.

The REJECTED and AUTH_REQUIRED states have no MCP counterpart. A remote agent can refuse a task, and it can pause to ask the client for a credential, for example an OAuth token to call a downstream API or a human approval before a destructive action.

MCP Tasks and stateless requests

MCP took the opposite direction in 2026. The 2026-07-28 revision made the core protocol stateless and moved tasks into an extension. Under the Tasks extension, a server can return a durable task handle instead of blocking; the client polls tasks/get, supplies mid-flight input through tasks/update, and may cancel. Task statuses are working, input_required, completed, failed and cancelled.

That narrows the gap on long-running tool calls, such as a CI pipeline triggered through MCP. It does not make an MCP server an agent. The extension is opt-in on both sides, and its documented statuses include no rejection state; nothing in it describes skills, peer identity or grouping related tasks into a conversation.

Transports and protocol bindings

MCP defines two standard transports, stdio for local subprocesses and Streamable HTTP for remote servers, both carrying JSON-RPC. A2A defines three bindings over HTTP-based transports, JSON-RPC, gRPC and HTTP+JSON/REST, with a requirement that all three behave identically.

The MCP transport page treats each transport as a binding that frames and delivers messages without changing their meaning. On Streamable HTTP, each message is an HTTP POST to one endpoint, and replies arrive either as a JSON object or as a stream scoped to that request. The 2026-07-28 revision removed session IDs and stream resumability: a broken stream loses the in-flight request, which the client must re-issue. The older HTTP+SSE transport is now formally deprecated.

stdio is the reason MCP spread so quickly on developer machines. A local server is a subprocess the host launches, with credentials read from the environment. The authorization specification says stdio implementations “SHOULD NOT” follow the OAuth flow and should take credentials from the environment instead.

A2A has no local-subprocess transport. Its specification requires HTTPS for HTTP-based bindings and TLS for gRPC in production, recommends TLS 1.3, and registers the media type application/a2a+json and the A2A-Version and A2A-Extensions headers. An Agent Card can list several interfaces, and the client picks the first one it supports. That design assumes agents are network services owned by someone else, which is the cross-team, cross-company case A2A was built for.

Authentication and authorization

MCP makes authorization optional and, when used over HTTP, profiles OAuth 2.1 with the MCP server acting as a resource server. A2A requires every request to be authenticated against schemes the Agent Card declares, and leaves authorization policy to each agent. Neither protocol defines who may call which tool or skill.

The MCP authorization specification builds on a subset of OAuth standards: the OAuth 2.1 draft, bearer tokens, authorization server metadata (RFC 8414), resource indicators (RFC 8707), protected resource metadata (RFC 9728) and, new in this revision, issuer identification (RFC 9207). It recommends Client ID Metadata Documents for client registration. A longer treatment of OAuth 2.1 patterns for MCP tool access covers the flows.

A2A’s security objects support API keys, HTTP authentication, OAuth 2.0 (authorization code with an optional PKCE requirement, client credentials and device code), OpenID Connect and mutual TLS. Version 1.0 removed the implicit and password grants. Credentials are obtained out of band and sent with every request; the server “MUST authenticate every incoming request.” Authorization is implementation-specific and may consider the skill requested, the action attempted, data access policies or OAuth scopes. List and get operations must return only tasks the caller is allowed to see.

The practical gap is the same in both: the protocol carries identity, but fine-grained policy, such as “the finance agent may call post_payment but the support agent may not,” is left to the implementation. That is where gateways and policy layers enter, covered below and in the Frontier Wire’s comparison of MCP gateways on security and control.

How A2A and MCP work together

The two protocols compose in layers. An orchestrating agent uses A2A to delegate work to remote agents owned by other teams or partners, and each of those agents uses MCP to reach its own tools and data. Appendix B of the A2A specification describes this pattern, and the MCP and A2A projects describe the protocols as complementary.

The A2A documentation’s comparison page walks through an auto repair shop. A customer’s assistant talks to a “Shop Manager” agent over A2A. The manager assigns a “Mechanic” agent, which uses MCP to call a diagnostic scanner, a repair manual database and a platform lift. When a part is needed, the mechanic contacts a “Parts Supplier” agent, run by another company, over A2A. Conversational, multi-step, cross-boundary work runs on A2A; structured calls to known functions run on MCP.

The same page notes one overlap: an A2A server can expose some skills as MCP-compatible tools when they are “well-defined and can be called in a tool-like, stateless way.” The reverse also happens in practice. Microsoft’s Foundry Agent Service treats a remote A2A agent as a tool type: its documentation describes a generally available a2a tool for connecting a Foundry agent to an A2A endpoint.

Framework support now covers both sides of the connection:

• Google’s Agent Development Kit has quickstarts for exposing and consuming A2A agents.
• CrewAI treats A2A as a first-class delegation primitive, with separate client and server configuration.
• LangChain’s Agent Server serves an A2A endpoint at /a2a/{assistant_id} that speaks the v1.0 JSON-RPC binding and still accepts v0.3 method names.
• The A2A project lists LangGraph, CrewAI, Pydantic AI, AG2 and IBM BeeAI among supporting frameworks, and Google Cloud, AWS Bedrock AgentCore Runtime and Microsoft Azure AI Foundry among clouds with native support.

For teams choosing a framework before choosing protocols, the Frontier Wire’s guides to open-source agent orchestration frameworks and enterprise agent orchestration platforms note which ones ship A2A and MCP support.

Governance, ACP and the Agentic AI Foundation

Both protocols are now governed by the same body. MCP was a founding project of the Linux Foundation’s Agentic AI Foundation in December 2025, and A2A joined it as a Growth Stage project in August 2026. IBM’s competing Agent Communication Protocol merged into A2A in 2025.

The timeline:

The ACP merger settled the “ACP vs MCP” and “ACP vs A2A” questions that circulated in 2025. The LF AI & Data announcement said the ACP team would wind down active development and contribute to A2A, with a migration guide for BeeAI users.

The A2A project’s August 2026 post claims backing from more than 150 organizations and production use in supply chains, financial services and mobile platforms; these are the project’s own figures. Under one foundation, the protocols share a governance home but keep separate specifications, maintainers and release processes.

Governing the MCP hop with a gateway

A gateway governs the hops an agent makes to models and tools. In an A2A system, each agent still makes MCP calls and model calls, and those are where credentials, spending and destructive actions live. An MCP gateway centralizes authentication, per-caller tool allow-lists and logging for that traffic.

Bifrost serves as the worked example here because its documentation covers each of these controls and the project is open source and self-hostable. Bifrost is an open-source AI gateway written in Go, released by Maxim AI under Apache 2.0, that routes model calls to 25+ providers and 10,000+ models through one OpenAI-compatible API. Its published benchmark reports 11 µs of added overhead per request at 5,000 RPS on an AWS t3.xlarge.

Figure 3: The agent-to-agent hop stays on A2A; every model call and tool call below it passes one set of keys and allow-lists.

On the MCP side, the Bifrost MCP documentation describes the gateway as both an MCP client, connecting to upstream servers over STDIO, HTTP or SSE, and an MCP server that exposes the aggregated tools on a single /mcp endpoint to clients such as Claude Desktop and Cursor. The controls that matter in a multi-agent design:

• Explicit execution by default. Tool calls returned by a model are suggestions; execution requires a separate call, unless agent mode is configured to auto-execute named tools.
• Per-key tool allow-lists. MCP tool filtering ties each virtual key to an allow-list of MCP clients and tools, deny-by-default, and enforces it again at execution time. Giving each A2A agent its own virtual key turns “the support agent may not call post_payment” into configuration.
• Upstream authentication. Six MCP auth types cover none, static headers, admin OAuth, per-user headers, per-user OAuth and token exchange, so an agent acting for a user can call an upstream server under that user’s identity.
• Scoped endpoints. Virtual MCPs bundle tools from several servers into one addressable /mcp/<slug> endpoint.
• Token cost. Code mode has the model write Python to orchestrate tools in a sandbox instead of loading every tool definition; the docs report input-token reductions of up to 92.8%.

The agent-to-agent hop itself runs on A2A and pairs with whatever A2A runtime or framework the agents use; the gateway sits beneath each agent on the model and tool side. The Bifrost team’s essay on MCP as protocol, plumbing and gateway sets out the reasoning for putting tool traffic behind a gateway.

A guide to what an MCP gateway does for production agents covers the category, and a survey of open-source agent gateways for MCP and A2A compares projects across both hops. The MCP gateway resource page summarizes Bifrost’s MCP feature set. Enterprise tier. Token exchange, MCP tool groups, guardrails and audit logs are part of Bifrost Enterprise.

Security risks on each protocol

Each protocol has a characteristic attack surface. MCP’s risks concentrate on tools: confused-deputy OAuth flows, token passthrough, server-side request forgery and instructions hidden in tool descriptions or results. A2A’s risks concentrate on identity and delegation: spoofed Agent Cards, over-broad task visibility and webhook abuse through push notifications.

The MCP security best practices document names confused deputy attacks, token passthrough (servers “MUST NOT accept any tokens that were not explicitly issued” for them), SSRF, state handle hijacking and local server compromise. The base specification adds that tool descriptions and annotations “should be considered untrusted, unless obtained from a trusted server,” and that hosts must get user consent before invoking any tool. The Frontier Wire’s survey of MCP security tools maps products to those risks.

A2A’s security considerations take a different shape:

• Card integrity. Signed Agent Cards let a client verify origin; unsigned cards fetched over plain discovery are only as trustworthy as TLS and DNS.
• Scoping. Servers must run authorization checks on every operation and must not leak the existence of tasks outside a caller’s scope.
• Push notifications. Agents calling webhooks should reject private IP ranges, localhost and link-local addresses to prevent SSRF, and clients must validate webhook authenticity and process deliveries idempotently.
• In-task authorization. The AUTH_REQUIRED state lets an agent ask the client for a credential mid-task, which means the client must judge whether a remote agent’s request for more access is legitimate.

Both protocols share one weakness neither can fix at the protocol level: content passed between agents, or returned by tools, can carry instructions that a model follows. A remote agent’s artifact is untrusted input in the same way an MCP tool result is. That is a prompt injection problem, and it calls for content guardrails and human approval on high-impact actions in addition to protocol-level authentication.

Choosing A2A, MCP or both

Use MCP when an agent needs structured access to tools, data or prompts that a team controls or can install. Use A2A when work must be handed to another agent that keeps its own tools and reasoning, especially across team or company boundaries. Most multi-agent systems end up using both.

Three questions settle most cases. Does the callee reason and plan, or does it run a defined function? Is it owned by someone else who will not expose its internals? Does the work need conversation, rejection or mid-task authorization? A “yes” to any of them points to A2A. If every answer is “no,” an MCP tool is simpler and easier to secure.

Two caveats limit how far the comparison can be pushed. Adoption figures for both protocols come mostly from the projects and their sponsors, not independent measurement. Both specifications also moved quickly in 2026, and SDKs and products lag the specifications: a framework that advertises “A2A support” may implement v0.3 rather than v1.0, and an MCP client may still use the pre-2026 handshake. Checking the protocol version a product actually speaks is part of any evaluation.

The A2A vs MCP framing outlived its usefulness once both projects landed in the same foundation and described themselves as layers of one stack. The decision that remains is architectural: where the boundary between “my agent’s tools” and “someone else’s agent” falls, and which controls apply on each side of it. Teams that draw that line explicitly, with MCP below it, A2A across it and authorization enforced on both, will find the protocols cooperate rather than compete.