MCP and A2A keep getting lumped together as competing agent protocols, but they standardize different layers entirely — one connects an agent to its own tools, the other connects independent agents across a trust boundary. Here's where that line actually falls, and when you need both, one, or neither.
Three agents into a project, someone in the design review asks: "shouldn't this be using A2A?" It's a reasonable question, and most teams answer it badly, because the two protocols that get bundled together as "the agent protocols" — the Model Context Protocol (MCP) and Google's Agent2Agent (A2A) — don't actually compete. They standardize different layers of the stack, and conflating them is how teams end up either bolting a cross-organization protocol onto a system one team fully owns, or trying to make MCP do a job it was never designed for.
MCP, Anthropic's late-2024 standard for connecting a model to tools, resources, and prompts, is now almost two years old and has become the default way an agent reaches into a database, a SaaS API, or a file system. A2A, which Google introduced in April 2025 and donated to the Linux Foundation two months later, solves a problem MCP doesn't touch at all: how does one agent — built by a different team, running on a different framework, possibly owned by a different company — ask another agent to do something, without either side having to expose its internal tools, memory, or logic? In March 2026, A2A shipped its first stable v1.0 specification; by its one-year anniversary under Linux Foundation governance it had more than 150 supporting organizations and production use inside several large enterprises. Both protocols now live as sibling projects under the Linux Foundation's Agentic AI Foundation (AAIF). The governance has converged. The jobs haven't.
MCP's architecture has three roles: a host (the application coordinating everything — Claude Desktop, an IDE, your own agent runtime), a client inside that host for each connection, and a server that exposes capabilities. A server offers those capabilities through three primitives — tools the model can invoke, resources that supply read-only context, and prompts that template reusable workflows — over JSON-RPC, either locally over stdio or remotely over HTTP with streaming.
Two properties of that design matter for the comparison that follows. First, the interaction is hierarchical: a client calls down into a server, the server executes, and the server waits to be called again. It doesn't reach back out and initiate anything on its own. Second, there's no built-in discovery: you point a client at a server endpoint you already know about and trust. MCP assumes you're wiring together capabilities you have some relationship with — your own services, a vendor's documented integration, a package you installed — not discovering a stranger's agent at runtime.
That's exactly the shape you want for "give my agent access to Postgres" or "let my agent call Stripe's API." It's the wrong shape for "let my agent negotiate with a travel agency's agent that I've never talked to before and whose internal tools I'm not allowed to see."
A2A exists for that second case: independent, potentially opaque agents that need to collaborate across a trust boundary. It defines a different set of primitives built for peer-to-peer delegation instead of hierarchical tool calls.
An Agent Card is a JSON document, conventionally served at /.well-known/agent.json, that an agent publishes to describe itself: its name and description, its endpoint URL, which authentication schemes it accepts, which protocol versions it supports, and — critically — its skills: the discrete things it knows how to do. A client agent fetches a card before it ever sends a task, decides from the card whether the remote agent can help and how to authenticate, and only then opens a conversation. A simplified card looks like this:
{
"name": "flight-fare-search-agent",
"description": "Searches and holds fares across partner airlines",
"url": "https://flights.partner-airline.example/a2a/v1",
"protocolVersion": "1.0",
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"securitySchemes": {
"oauth2": {
"type": "oauth2",
"flows": { "clientCredentials": { "tokenUrl": "https://auth.partner-airline.example/token" } }
}
},
"skills": [
{
"id": "search-fares",
"name": "Search Fares",
"description": "Search available fares for a route and date range",
"tags": ["travel", "flights"]
}
],
"defaultInputModes": ["text", "data"],
"defaultOutputModes": ["text", "data"]
}
With v1.0, Agent Cards can be cryptographically signed, so a client can verify that the card it fetched actually came from the organization it claims to represent — an enterprise requirement MCP has no equivalent for, since MCP assumes you already know and configured your server.
Where an MCP tool call is a single request-response, an A2A Task is a stateful unit of work with an explicit lifecycle: submitted, working, input-required, completed, failed, canceled. A task can pause in input-required for hours while a human approves something, then resume. Agents exchange Messages made of Parts (text, structured data, or file references) while the task runs, and the remote agent returns its results as Artifacts — the task's concrete deliverables. A contextId groups the messages and tasks that belong to one ongoing interaction, which matters for a negotiation that spans multiple back-and-forth turns instead of one call.
Transport-wise, A2A also runs JSON-RPC 2.0 over HTTP, so it isn't a radical departure from MCP's plumbing — but it adds Server-Sent Events for streaming updates and webhook-based push notifications, which exist specifically because A2A tasks are built to run for minutes, hours, or days, not milliseconds. The v1.0 spec widened this further with support for multiple protocol bindings (JSON-RPC, JSON+HTTP, and gRPC) and explicit version negotiation, so agents built on different stacks can still interoperate.
The cleanest way to see the split is a multi-party booking flow. A customer-facing orchestrator agent your team owns needs to book a trip. It doesn't maintain its own flight-search logic or hotel inventory — it delegates to a flight specialist agent run by an airline partner, and a hotel specialist agent run by an OTA. Neither partner is going to hand your orchestrator direct access to their internal booking database; they'll hand it an agent that decides what to expose. That handoff — orchestrator to flight agent, orchestrator to hotel agent — is A2A: peer delegation across a boundary neither side controls. Inside the flight agent, though, the job of actually querying the airline's fare API or inventory database is MCP: a tool call the flight agent's own model makes to its own, privately-owned capability.
The dimension-by-dimension version of the same split:
| Dimension | MCP | A2A |
|---|---|---|
| What it connects | An agent to its own tools, resources, and prompts | One agent to another, independently owned agent |
| Interaction shape | Hierarchical — client calls, server answers | Peer-to-peer — either side can be the delegator |
| Unit of work | A single tool call, request/response | A stateful Task with a lifecycle and pauses for approval |
| Discovery | None — you configure a known server endpoint | Agent Cards published at a well-known URL, fetched before contact |
| Transport | JSON-RPC over stdio or streamable HTTP | JSON-RPC, JSON+HTTP, or gRPC over HTTP, plus SSE and webhooks |
| Trust model | You already trust the server; it's yours or a vendor's documented one | Designed for agents that don't share internal tools, memory, or logic |
| Governance | Agentic AI Foundation (Linux Foundation) | Agentic AI Foundation (Linux Foundation), since August 2026 |
The instinct to reach for A2A scales with the number of agents in a system, but that's the wrong trigger. A team running four or five agents that all live in one codebase, share one deployment, and answer to one set of permissions doesn't have an interoperability problem — it has an orchestration problem, and a framework like LangGraph or CrewAI inside a single trust boundary solves it without a network protocol in the middle. A2A earns its overhead — the extra hop, the authentication handshake, the Agent Card lookup — specifically when the agent on the other end brings its own identity and its own permissions that your system has to respect rather than override. That's a boundary question, not a headcount question: do the agents sit behind separate security scopes owned by different parties, or do they all answer to the same team?
It's worth being honest about how early this still is in practice. A2A's adoption numbers are real, but most systems that get called "multi-agent" today are one team's orchestrator calling a sequence of tools it fully owns — which is an MCP problem wearing a multi-agent costume, not an A2A one. Genuine cross-organization, cross-framework agent traffic, where one company's agent negotiates with a stranger's agent it discovered via an Agent Card, is still the exception. LinkedIn is one of the more concrete public examples of a large org running both protocols together for its enterprise agent platform, and even there, A2A was described as the more experimental of the two as of late 2025. The honest framing is: MCP is mature and nearly ubiquitous; A2A is standardized and increasingly deployed, but the "independent agent economy" it's built for is still mostly ahead of us rather than already here.
Adopting both protocols correctly still leaves real architecture work undone, and it's worth naming it rather than discovering it in production.
Neither spec unifies state across a workflow. A2A's contextId groups the tasks and messages inside one negotiation, but nothing ties that identifier to the MCP server state the flight agent touched while handling it, or to the orchestrator's own memory of the conversation. If you need to reconstruct "what actually happened" across an A2A hop and the MCP calls each side made underneath it, that correlation is something your own logging has to build — the protocols hand you message envelopes, not a unified trace.
Observability gets harder for the same reason: once an agent starts delegating to other agents instead of just calling its own tools, it becomes genuinely difficult to tell which hop produced a given answer, and agents are less deterministic than a plain function call, so even confirming that a delegated task ran correctly takes real instrumentation. And there's still no standard for agent memory itself — how an agent persists what it learned mid-task so it survives a crash or a user coming back three days later is left entirely to whoever builds the agent, on either side of either protocol.
None of that is a knock on the protocols; it's a reminder that "we adopted MCP and A2A" answers the transport question, not the state, memory, or observability questions sitting underneath it.
Don't let "which agent protocol should we use" become a single question with a single answer. Ask it twice: does this agent need to reach its own tools and data (MCP), and does this agent need to hand work to an agent it doesn't own and can't see inside of (A2A)? Most systems today need the first and not the second. If you're building a tool an agent calls — even something as small as a single-purpose utility like a checksum validator or a unit converter — exposing it over MCP, the way Utilix's own MCP server does for its developer tools, is the layer that actually matters right now; A2A is the layer you'll reach for once your agents start needing to talk to agents you don't control.