"A2A or MCP?" reads like a choice between two competing standards. It isn't. The two protocols sit at different layers of an agent system, and most production architectures end up running both.
The Model Context Protocol connects a single agent down to the tools and data it needs to act. The Agent2Agent protocol connects agents across vendors, frameworks, and organizations. One is vertical, agent to tool. The other is horizontal, agent-to-agent, and the agent on the other side can belong to a company you've never worked with.
This guide covers where A2A and MCP diverge, what each one is built for, and how to decide which layer, or both, an architecture needs.
Key takeaways:
MCP connects one agent to tools and data; A2A connects agents, and production multi-agent systems commonly run both layers at once.
A2A models work as long-lived tasks with a defined lifecycle, while MCP centers on a client-server model for server capabilities.
A2A shipped its 1.0 stable release with public support from more than 150 organizations, while MCP planning should start with the clients and servers a team's own system needs to support.
Vercel hosts web-facing agent workloads with fluid compute for agent endpoints and the AI SDK for streaming interfaces, alongside MCP server docs for deploying remote MCP servers.
Copy link to headingWhat are the key differences between A2A and MCP?
The two protocols differ in what each one assumes about the other side of the connection. MCP assumes the other side is a capability the agent controls. A2A assumes the other side is a peer that reasons independently.
That single assumption cascades into every operational difference between them, from how each side discovers the other to how long an interaction can run:
Every row traces back to the same design decision. MCP standardizes a single agent's access to capabilities, while A2A standardizes negotiation between peers that don't share a trust boundary.
Copy link to headingA deep-dive into A2A for cross-organization agent coordination
Agent2Agent (A2A) is an open protocol for communication and coordination between AI agents. It's the layer teams reach for when the other side is a reasoning system they don't own, built on a different framework, or operated by another organization.
Where MCP describes capabilities, A2A describes collaborators. Its core abstraction is a task that two agents track together from submission to a terminal state, with a contextId grouping related tasks and messages into a single logical thread.
Copy link to headingKey components that make A2A work
A2A's building blocks map onto a single idea: two agents track a single piece of work together from the moment a client agent finds a remote agent until the work is resolved. Six pieces carry that idea end to end:
Agent Card: A JSON document at /.well-known/agent-card.json publishing an agent's name, description, version, service endpoint, supported modalities, authentication requirements, and skills.
Task: The stateful unit of work a remote agent returns for anything that takes real time, tracked from submission to a terminal state.
contextId: An identifier that groups related tasks and messages into one logical thread so that a remote agent can follow a conversation across multiple requests.Message: A lightweight, immediate response a remote agent sends for trivial interactions that don't need task tracking.
Parts: The contents of a message, holding text, raw data, a URL, or structured data.
Artifacts: The tangible output of a task, which can stream incrementally as work progresses instead of arriving only at completion.
Together, they let a client agent discover a remote agent, decide whether a request needs a Task or a Message, and follow that work to a result without either side losing track of the other.
Copy link to headingAdvantages and limitations of A2A
An agent can work with another agent it doesn't control because A2A provides both sides with the same methods and data structures, regardless of framework or vendor. Each exposed agent retains the ability to reason, ask clarifying questions, and manage its own state, rather than being reduced to a stateless function call.
The advantages A2A brings to a cross-boundary architecture:
Framework and vendor independence: Agents built on different platforms communicate via a single shared protocol rather than custom point-to-point integrations.
Preserved agent autonomy: A remote agent can refuse a request, ask for more input, or return partial results, none of which fits a narrow tool call.
A stable, production-ready spec: Version 1.0 adds multi-tenancy and a web-aligned architecture built for the load balancers and gateways teams already operate, alongside signed Agent Cards available since v0.3.0.
None of that removes the operational work of coordinating with an agent nobody on the team built. A2A gives both sides a shared protocol, not a shared ownership boundary, so the details below still land on whoever operates the client side of the connection.
Teams adopting A2A still have to handle real operational details:
Registry-light discovery: Discovery is card-based rather than registry-backed, so finding the right remote agent still depends on knowing where to look.
Out-of-band credentials: Authentication requirements are declared in the card, but the credentials themselves are exchanged separately, outside the protocol.
A long-lived endpoint per remote agent: Every remote agent needs a permanent HTTP endpoint, not a short-lived function that spins down between calls.
Inconsistent update-delivery support: Polling, SSE, and webhooks are all valid per the spec, so verify which ones a given integration implements before building against it.
Those costs are the price of coordinating with an agent a team doesn't control, and they're worth planning for before the integration, not after.
Copy link to headingCommon A2A use cases
A2A earns its overhead in three recurring situations, each one defined by what's on the other end of the connection rather than by industry or use case.
Copy link to headingThe remote system reasons on its own
If the system being called makes autonomous decisions rather than returning a fixed output, it's a peer agent, not a tool. A2A preserves its ability to negotiate, ask clarifying questions, and manage its own state, which a narrow tool call can't represent.
Copy link to headingTasks run long and need back-and-forth
Work that pauses for input, requires clarification, or streams partial results over hours maps directly onto A2A's task lifecycle. TASK_STATE_INPUT_REQUIRED exists specifically for that kind of multi-turn negotiation, giving both sides a shared view of work that can pause without losing task identity.
Copy link to headingWork crosses a vendor or organizational boundary
A cross-organizational workflow can involve one company's agent coordinating with another company's agent while each side maintains its own systems and disclosure rules. Once ownership splits, A2A gives both parties a common shape for discovery, authentication, task state, and result exchange.
Copy link to headingExploring MCP for tool and data access
The Model Context Protocol (MCP) is an open standard that defines how an AI application connects to external server capabilities over JSON-RPC 2.0. It's the layer teams reach for when the other side is a capability rather than a collaborator, such as a database, a third-party API, or an internal service that returns the same output for the same input.
MCP follows a client-host-server architecture, and the specification is versioned, providing a single agent with standard access to external systems through an interface shared across all MCP-capable clients.
Copy link to headingKey components that make MCP work
MCP's architecture separates who controls the connection from who controls what gets exposed over it, and that separation is what lets a single server safely serve many unrelated clients. Six pieces make up that architecture:
Host and client: The host process, a desktop AI application or a team's own application, is the container and coordinator. It enforces security policy and user consent, and it creates one client per server, keeping each client isolated from the others.
Server: The process that exposes context to a client. A team can run one server per tool or data source, or bundle related capabilities into a single server.
Tools: Model-controlled functions the LLM discovers and invokes on its own to take an action, such as calling an API or writing to a database.
Resources: Application-controlled structured data identified by a URI, such as a file or a database record, that the host decides when and how to surface.
Prompts: User-controlled templates that require explicit invocation rather than automatic triggering, giving a person a repeatable, parameterized way to use a server's capabilities.
Transport: The channel carrying JSON-RPC messages between client and server, either stdio for a local subprocess or Streamable HTTP for a remote server.
Clients and servers negotiate which of these each side supports during initialization, and a per-primitive-type listing method determines what is actually on offer.
Copy link to headingAdvantages and limitations of MCP
One MCP server can expose the same capability to every MCP-capable client a team runs, without rebuilding the integration separately for each host application. The client-server model also keeps authorization, validation, and orchestration outside the LLM, where a team can reason about them directly.
The advantages MCP brings to a single agent's integration surface:
Write-once tool exposure: A server built once works with every client that speaks MCP, rather than a custom integration per host.
Authorization outside the model: Access control, validation, and orchestration logic live in the server and host, not in the LLM's own judgment.
A shared interface across the ecosystem: Teams adopting new MCP-capable clients don't need to rebuild the tool layer underneath them.
That write-once model covers the surface the spec defines. It says nothing about the parts of a production integration the spec deliberately leaves to the implementer.
Teams still need to plan for what the spec leaves open:
No pre-connection discovery document: No spec revision defines a connection-free discovery document, so client configuration still happens out of band. A well-known server card remains an open proposal, and the separate MCP Registry is in preview rather than part of the spec.
Task semantics are still settling: Tasks arrived in the November 2025 revision with tasks/get, tasks/cancel, and status notifications, and were then moved out of core into an official extension in the July 2026 revision, so a team building on them should pin a spec revision rather than assume stability.
No memory primitive: The spec doesn't define a way for a server to persist context across sessions, leaving that entirely to the application built around it.
Optional authorization: Supporting authorization at all is optional, so whether to enforce it is a deliberate implementation decision. Once a server supports it, the spec's requirements for protected-resource metadata and PKCE are mandatory rather than advisory.
None of these gaps disqualifies MCP for the job it's built for. They're the reason a production MCP server still needs an integration plan around it, not only a schema.
Copy link to headingCommon MCP use cases
MCP earns its place in three recurring situations, each one defined by what the agent is reaching for rather than by industry or use case.
Copy link to headingOne agent needs systems it doesn't own
When an agent has to reach databases or third-party APIs, MCP standardizes that access once, and the same server works across every MCP-capable client a team runs. The integration boundary here is the tool or data source itself, not another agent.
Copy link to headingThe remote side is deterministic
If a system produces the same output for the same input, it belongs behind a tool interface rather than an agent protocol. That keeps the reasoning with the calling agent while the remote side handles the deterministic capability without added protocol overhead.
Copy link to headingCompatibility across AI clients matters
When the goal is to reach across multiple AI applications, MCP's protocol boundary is the feature. A single Streamable HTTP server serves every MCP-capable client a team supports, giving the tool provider one shape to implement and the host one shape to call.
Copy link to headingHow Vercel supports A2A and MCP agent workloads
Both protocols turn into infrastructure the moment a team adopts them, requiring long-lived endpoints, durable state, streaming, and scoped auth. Vercel covers the web-facing parts of that shape for agent systems built as HTTP services.
Copy link to headingHosting a long-lived A2A endpoint on Fluid compute
An A2A remote agent is an always-on public service that serves an Agent Card, accepts task submissions, and handles concurrent requests from clients that a team doesn't control. Most of its wall-clock time goes to waiting on a model call, a downstream API, or a human, not computing.
Fluid compute suits that shape, since one instance handles many concurrent requests and Active CPU billing pauses entirely during I/O, though provisioned memory keeps billing at its standard rate. Vercel Functions run for 300 seconds by default, and up to 800 on Pro and Enterprise, which covers waits measured in minutes.
For a task parked in TASK_STATE_INPUT_REQUIRED for hours, Vercel points at Vercel Workflows instead, since paying for an idle instance stops making sense well before the duration ceiling does.
Copy link to headingPersisting task state with a Marketplace database
A2A tasks stop in TASK_STATE_INPUT_REQUIRED and wait until a human or another agent responds, and that wait routinely outlasts a single function invocation. The function itself has to stay stateless between calls, so task status, pending input, artifacts, and correlation IDs need somewhere durable to live outside the request.
A Vercel Function hosts the HTTP entry point. At the same time, a database provisioned through Vercel Marketplace, Postgres via Neon, or a low-latency store via Upstash holds the task record the endpoint reads and updates on every call.
That split keeps the public agent route on Vercel while making task persistence an explicit, inspectable part of the application rather than something the request lifecycle happens to provide.
Copy link to headingStreaming task updates with the AI SDK
A2A deliberately lets clients choose polling, SSE streaming, or webhooks to receive task updates, and the right mode depends on whether the consumer is a browser or a backend agent service.
Browser consumers need the same kind of incremental delivery a chat UI already relies on:
import { streamText } from 'ai';
export async function POST(req: Request) { const { taskId } = await req.json();
const result = streamText({ model: 'anthropic/claude-sonnet-4.5', prompt: `Summarize progress on task ${taskId}`, });
return result.toTextStreamResponse();}The AI SDK's streaming primitives, built for token-by-token chat output, carry A2A artifact updates through the same SSE connection to the browser. Backend consumers skip streaming entirely and implement polling or webhook routes as ordinary HTTP handlers, so the endpoint contract stays consistent even as the delivery mechanism changes by consumer.
Copy link to headingDeploying an authorized MCP server with mcp-handler
MCP authorization is optional at the protocol level, but once a server supports it, the spec's requirements become mandatory.
A production server exposing read or write access to team data, therefore, has to make scoped authorization part of its own route design. Vercel's MCP server docs show the mcp-handler package wrapping a server's tool definitions with withMcpAuth, which verifies a bearer token before any tool executes:
import { withMcpAuth } from 'mcp-handler';
const authHandler = withMcpAuth(handler, verifyToken, { required: true, requiredScopes: ['read:stuff'], resourceMetadataPath: '/.well-known/oauth-protected-resource',});
export { authHandler as GET, authHandler as POST };The helper is still published under both withMcpAuth and experimental_withMcpAuth, so pin the version rather than treating the signature as settled.
The MCP server route deploys in the same Vercel project as the rest of the application, along with its environment variables, logs, and deployment workflow. Hence, token verification and scope checks live next to the tool surface they protect, rather than in a separate service that must be kept in sync.
Copy link to headingChoosing between A2A, MCP, both, or neither
Choose by integration boundary rather than feature comparison, weighing tool access, agent-to-agent coordination, internal ownership, or some combination of the three.
Copy link to headingOne agent needs tools or data it doesn't own
If a single agent needs to access databases, storage, or third-party APIs, MCP handles it without incurring multi-agent overhead. One agent plus external capabilities is the textbook MCP case, and reaching for A2A here adds coordination cost a single-agent integration doesn't need.
Copy link to headingAgents cross a vendor or organizational boundary
When the other side of the wire is an agent someone else built or operates, A2A is the layer that lets a team discover it, authenticate to it, and track a shared task. Each agent can still use MCP internally for its own tools, which keeps the two boundaries clean: MCP governs the agent-to-tool relationship, and A2A governs the space between agents.
Copy link to headingEverything runs in one codebase under one team
Ownership boundaries matter more than agent count. If every agent lives in a single codebase under a single team, then framework-native subagent or handoff patterns, or plain function calls, are simpler and faster than either protocol. A protocol between components a team fully controls adds serialization and network hops while adding little interoperability benefit.
Copy link to headingAgents delegate across boundaries and each needs tools
Systems with both cross-boundary delegation and tool access land here, and this is where the operational surface gets real. A2A manages delegation between agents, while MCP gives each agent its own tools.
That architecture obliges a team to operate HTTPS endpoints, publish Agent Cards, manage out-of-band credential infrastructure, track task lifecycle state, run an MCP server per tool or data source, and correlate logging across every A2A message and MCP call.
Treating those as first-class infrastructure requirements, not afterthoughts, makes the protocol choice easier to run in production.
Copy link to headingShip your agent stack on the right protocol layers
If the starting question was A2A versus MCP as alternatives, the honest answer is that they complement each other. MCP wires each agent to its tools. A2A wires agents to each other across boundaries that neither side controls.
Which combination of architecture an organization needs depends on team context, and the operational surface underneath either one stays consistent, needing durable endpoints, parked task state, multi-mode streaming, and scoped authorization.
Vercel maps those requirements to concrete products:
fluid compute: I/O-heavy agent endpoints run on active-CPU pricing, so waiting on a model or a human doesn't run up the bill.
AI SDK: Streaming patterns for both A2A task updates and MCP tool responses run through the same primitives teams already use for chat interfaces.
MCP server docs: A deployment path for remote MCP servers, including OAuth, on the same project as the rest of an application.
Vercel Functions: Long-running, concurrent HTTP endpoints for the discoverable, always-on services both protocols require.
Start a new project at vercel.com/new to put an agent endpoint into practice, or browse vercel.com/templates for a deployable starting point.
Copy link to headingFrequently asked questions about A2A vs MCP
Copy link to headingWhat happened to the Agent Communication Protocol (ACP)?
ACP merged into A2A. IBM Research built it for BeeAI in early 2025, and LF AI and Data announced the merger in August 2025. After that, ACP development wound down, migration guides were published, the repository was archived, and IBM took a seat on the A2A technical steering committee. Teams with an ACP-era integration should compare their task, message, and authentication behavior against the A2A implementation they plan to adopt.
Copy link to headingIs A2A still a Google project?
A2A is a cross-vendor interoperability protocol hosted by the Linux Foundation, with public support from more than 150 organizations and a technical steering committee holding seats at AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. For engineering planning, the more useful question is whether a target remote agent publishes an Agent Card, supports the required task lifecycle, and exposes the authentication a team can satisfy.
Copy link to headingCan A2A replace MCP?
No, they operate at different layers. MCP manages an agent's access to tools and data, while A2A coordinates between agents. In production architectures, the common pattern is an MCP within each agent and A2A communication between agents, rather than a single protocol that substitutes for the other.
Copy link to headingHow do agents authenticate across A2A?
An Agent Card declares what a remote agent expects for authentication, while credentials themselves are exchanged outside the card. In production, treat that exchange as an HTTP service boundary: validate credentials before accepting task work, and keep authorization decisions tied to task state and the artifacts a remote agent can access.