MCP vs. A2A: Complementary or Competing?
Google says its new agent-to-agent protocol complements the Model Context Protocol; others aren't so sure. Here's how they compare.
On Wednesday, Google announced two big things:
Their intent to support Anthropic’s Model Context Protocol (MCP) — 🎉
Their own open standard: the Agent2Agent Protocol (A2A) —which they describe as complementary to MCP
Interestingly, these two announcements came in very different formats.
MCP support was confirmed via a tweet from Sundar Pichai, while A2A got a ~3000 word press release featuring 50 design partners.
Reactions to the announcement were mixed.
Some saw A2A as a marketing move dressed up as a complement to MCP:
Others were more optimistic, framing A2A as solving a different part of the interoperability puzzle: agent-to-agent communication, whereas MCP handles agent-to-tool interaction.
One of the creators of MCP, David Soria Parra, shared that Google had chatted with them about their plans and expressed support for exploring different standards:
Regardless of whether you see this as an augmentation of MCP or a competing alternative, this is big news for the world of AI protocols. This post will focus on what A2A is, how it compares to MCP, and what it might mean for the future.
P.S. If you’re not yet familiar with MCP, this post offers a good starting point!
What is the Agent-to-Agent Protocol (A2A)?
A2A is an open protocol created by Google, designed to help AI agents discover, communicate with, and coordinate actions across other agents.
Unlike MCP — which connects models to tools and data — A2A focuses on agent collaboration. It’s built with multi-agent systems in mind, and is multi-modal, supporting text, audio, and video interactions.
This matters because today, if you want multiple AI systems to work together, you typically:
Log into each one separately
Run them in parallel or in sequence
Manually pass results between them
With A2A, that orchestration becomes automatic. Agents can:
Discover one another
Share tasks
Pass results
Collaborate across different platforms
Google’s ambition here is clear: A2A is trying to enable modular agent ecosystems — where specialization and interoperability are both possible. And most importantly, where these details are abstracted away from the end user.
What does A2A allow AI agents to do?
According to Google, A2A supports four main capabilities:
Secure Collaboration — Agents can communicate with privacy and access controls baked in
Task & State Management — Long-running tasks persist across sessions and can store status/history
User Experience Negotiation — Agents can dynamically choose the best format or modality for delivery (e.g., voice, chat, doc)
Capability Discovery — Agents can advertise and find other agents with specific skills
In Google’s demo video (that’s buried in the A2A README), a user asks Google’s “Agentspace” agent to help source job candidates. Here’s what then happens under the hood (via A2A).
First, Google Agentspace launches the A2A protocol, and uses Capability Discovery to find a relevant Sourcing Agent:
Then, the protocol relies on Collaboration to ask the human user for feedback and to clarify role requirements:
Next, the agents ‘agree’ on the proper way to share back the data with the client, performing a User Experience Negotiation based on the available capabilities of the agent that’s interacting directly with the human, in this case, Google Agentspace:
Finally, Task and State Management allow the collaborating agents to keep track of where they are in the process and communicate that back over the course of long-running tasks:
It’s a compelling vision — and feels like a natural extension of the shift toward agentic computing.
How does the A2A protocol work?
At its core, A2A is a way for developers to describe agent capabilities in a machine-readable way, so that other agents can find and interact with them.
Two core components:
📄 Agent Cards:
An agent card is a JSON metadata file (basically, a piece of structured text) located at a consistent place (usually at
/.well-known/agent.json) describing:Agent name, description, skills
Supported modalities (e.g., text, voice)
Authentication requirements
Contact info or endpoints
Think of this like an agent’s LinkedIn profile.
📦 Tasks:
A structured unit of work shared between agents:
Created by a “client agent” (the one the user instructed to do something)
Executed by a “remote agent” (e.g. the Sourcing Agent in the example above)
Can persist over time (for long-running jobs)
Includes relevant data, documents, messages, and results (aka “artifacts”)
In practice, tasks act as a shared context object — helping agents stay in sync.
To learn more, you can read the full technical documentation of A2A here.
How do MCP and A2A compare?
Both MCP and A2A are:
Open standards
Built on shared protocols (like JSON-RPC and SSE)
Designed for interoperability
Focused on passing structured context between intelligent systems
But their roles differ:
MCP is focused on helping LLMs interact with data, resources, and tools.
A2A is focused on helping AI agents interact with other AI agents, incorporating user input.
In Google’s documentation, they emphasize the complementarity with a section titled “A2A ❤️ MCP.”
These diagrams from Google’s A2A docs show how Google imagines they might fit together.
Agents would use A2A to communicate one another, while MCP is used to provide agents with access to tools, such as APIs or third-party applications:
However, MCP server resources may also point to A2A Agent Cards:
Google’s framing implies that MCP is a bridge, but A2A is the protocol that spans the system.
A2A + MCP in Practice
Let’s imagine what a fully collaborative future for A2A and MCP might look like from Google’s perspective.
Let’s say you’re using Google Agentspace and ask:
“Help me research competitors’ marketing tactics and share updates in Slack.”
Here’s how A2A and MCP might work together:
A2A: Agentspace finds a marketing research agent
A2A: The two agents collaborate to define scope and expectations
MCP: Agentspace uses the Salesforce MCP to fetch relevant competitor data that’s specific to my company
A2A: Research agent completes the task and sends the artifact back
MCP: Agentspace uses the Slack MCP to notify you with the results
But as Solomon Hykes pointed out originally, the distinction between ‘agents’ and ‘tools’ is not often this clear.
While Google tries to distinguish agents (collaborators with state) from tools (stateless APIs), the reality is many MCP servers could be modeled as agents, and vice versa. As tools get more autonomous, that line is likely to blur even more.
Agent-to-Agent Marketing?
Another interesting implication of protocols like A2A is that (in most cases) users don’t choose which agent completes their task.
Instead, users choose the client agent (e.g. Google Agentspace in the example above), and that agent chooses its partners based on what’s in each agent’s metadata.
This raises questions like:
How do agents compete for selection?
Will there be a new field around optimization for Agent Cards (not SEO, but … ACO?)?
How will agents be ‘reviewed’?
Eventually details that we typically include in contracts: pricing, SLAs/response times, output format, might also all be included upfront to differentiate agents’ services. We may see agents specialize on increasingly small niches or focused tasks to differentiate.
Some folks (like Dharmesh Shah) are already thinking about directories, B2A (Business to Agent) sales and marketing, and the emergence of new categories like “Agent Experience Design.” It’s an interesting future to imagine.
Final thoughts
Google’s A2A protocol could end up being:
A genuinely useful open standard that helps realize agent-based computing at scale
A marketing move to own a layer of the AI stack
Or, most likely, a bit of both
But it’s clear that the era of protocol design for intelligent systems is heating up, and A2A is now firmly in the conversation alongside MCP.
Whether these systems remain “complementary” will depend on how open, interoperable, and collaborative the actual implementations turn out to be.
In the meantime, I’ll continue tracking how MCP and A2A evolve, and what they unlock, together or apart.