MCP vs. A2A: Friends or Foes?
Could MCP fade into irrelevance in long term?
👋 I am Aurimas. I write the SwirlAI Newsletter with the goal of presenting complicated Data related concepts in a simple and easy-to-digest way. My mission is to help You UpSkill and keep You updated on the latest news in GenAI, MLOps, Data Engineering, Machine Learning and overall Data space.
The success of MCP (Model Context Protocol) by Anthropic has clearly inspired other players in AI industry to join the race to be the ones to define open protocols that will be used in Agentic Systems integration.
This week Google comes out publicly with their open protocol called A2A (Agent2Agent) that is aiming to normalise how multi-Agent systems communication is implemented. Many are saying (misinterpreting?) that the two protocols are competitive rather than complimentary.
The public stance by Google is that A2A is complimentary to MCP. That is a reasonable statement. However, could there be hidden long term competitive goals? Will we see protocol wars start soon?
I have been asked multiple time how I believe the two protocols might become competitive in the future. Read until the end to get my thoughts on it.
In this Newsletter episode:
What is A2A?
What is MCP?
How is A2A complimentary to MCP and vice versa?
Could A2A eat up MCP long term?
A2A explained.
Let’s first define A2A as it is the new kid on the block (MCP already had its spotlight).
The problem.
It is becoming clear that Agentic Systems of the future will be multi-Agent. Even more, Agents will be collaborating between each other remotely, each of them potentially implemented using different Agent Frameworks (e.g. LangGraph, CrewAI, Agent Development Kit etc.).
There are few inherent problems with this:
System State transfer and exchange between systems implemented in different frameworks is not supported.
Transfer of the System State between remote Agents is also not possible.
Disconnected Agents do not share Tools, Context and Memory (including System State).
The solution.
A2A is an open protocol that provides a standard way for agents to collaborate with each other, regardless of the underlying framework or vendor.
As per official Google documentation:
A2A protocol facilitates communication between “client” and “remote” agent.
In simple terms, “client” agent creates tasks and communicates them to the “remote” agent expecting some work to be performed or data returned.
Main A2A capabilities facilitating this:
Capability discovery - all agents implementing A2A expose their capability catalogue via “Agent Card”. It helps other Agents discover potentially useful features implemented by the given Agent.
Task management - communication protocol that facilitates short and long-running tasks. It helps communicating Agents to stay in-sync until the requested task is completed and the answer returned. This is big because some Agents might take long time to execute their work and there are no standards on how to wait for this to happen.
Collaboration - Agents can send each other messages to communicate context, replies, artifacts, or user instructions.
User experience negotiation - this one is pretty interesting. It allows negotiating on the format the data should be returned in order to fit the user UI expectations (e.g. Image, video, text etc.).
Discovery of agents exposed via A2A is a big topic. Google suggests a unified place to store organisations “Agent Cards”. E.g.:
https://<DOMAIN>/<agreed-path>/agent.jsonThis is not unexpected as Google would then be in the best spot to index all of the available Agents world wide potentially creating a global Agent Catalogue similar to current search index.
There has been a lot of talk about headless browsers and how the future internet of Agents will be implemented. The above is one of the ways it could happen by leveraging already existing technologies.
I love how A2A stresses the need to not reinvent the wheel and is building on existing standards:
The protocol is built on top of existing, popular standards including HTTP, SSE, JSON-RPC, which means it’s easier to integrate with existing IT stacks businesses already use daily.
Secure by default - A2A is designed to support enterprise-grade authentication and authorization, with parity to OpenAPI’s authentication schemes.
MCP Explained.
MCP (Model Context Protocol) as defined by Anthropic is:
An open protocol that standardises how applications provide context to LLMs.
To be more precise it attempts to standardise the protocol on how LLM based applications integrate with other environments.
In Agentic systems the context can be provided in multiple ways:
External data - this is part of long term memory.
Tools - the capability of the system to interact with the environment.
Dynamic Prompts - that can be injected as part of the system prompt.
…
Why the need to standardise?
Current development flow of Agentic applications is chaotic:
There are many Agent frameworks with slight differences. While it is encouraging to see the ecosystem flourish, these slight difference rarely add enough value but potentially significantly change the way you write code.
Integrations with external data sources are usually implemented ad-hoc and using different protocols even within organisations. That is clearly true for different companies as well.
Tools are defined in code repositories in slightly different ways. How you attach tools to augmented LLMs is different as well.
The goal is to improve the velocity of how fast we can innovate with Agentic applications, how well we can secure them and how easy it is to bring relevant data to the context.
Bellow is the high level architecture of MCP.
MCP Host - Programs using LLMs at the core that want to access data through MCP.
MCP Client - Clients that maintain 1:1 connections with servers.
MCP Server - Lightweight programs that each expose specific capabilities through the standardised Model Context Protocol.
Local Data Sources - Your computer’s files, databases, and services that MCP servers can securely access.
Remote Data Sources - External systems available over the internet (e.g., through APIs) that MCP servers can connect to.
Splitting control responsibilities through MCP.
MCP Servers expose three main elements that are purposely built in a way that helps implement specific control segregation.
Prompts are designed to be User-Controlled.
Programmer of the server can expose specific prompts (suited for interaction with data exposed by the server) that can be injected into the application using LLMs and exposed to the user of the given application.
Resources are designed to be Application-Controlled.
Resources are any kind of data (text or binary) that can be used by the application built to utilise LLMs. The programmer of the application (usually AI Engineer) is responsible of codifying how this information should be used by the application. Usually, there is not automation in that and LLM does not participate in this choice.
Tools are designed to be Model-Controlled.
If we provide agency to our application of how it should interact with the environment we use tools to do that. MCP Server exposes an endpoint that can list all of the tools available with their descriptions and required arguments, application can pass this list to the LLM so that it can decide which tools are needed for the task at hand and how they should be invoked.
A2A + MCP.
As per official Google stance:
Agentic applications need both A2A and MCP. We recommend MCP for tools and A2A for agents.
What does it mean? Let’s look into an Agentic System architecture that involves multiple Agents.
Moving pieces in MCP:
MCP Host - This is where it gets interesting, when combined with A2A, MCP Host is the Agent.
MCP Client.
MCP Server.
Local Data Sources.
Remote Data Sources.
A2A:
Agents (MCP Hosts) would implement and communicate via A2A protocol, that enables:
Secure Collaboration - MCP lacks authentication. [Update: recently, there has been many improvements to authentication in MCP: link].
Task and State Management.
User Experience Negotiation.
Capability discovery - similar to MCP tools.
The suggestion is that MCP is used mostly for integrating legacy data systems (MCP Resources) and APIs (MCP Tools) with LLM based applications while A2A takes care of inter-Agent communication.
I do believe that as we move forward it will become more common to expose your platforms as Agents rather than MCP Servers so the importance of MCP in point 5. will gradually decrease.
Agent discovery via MCP.
Google goes as far as suggesting exposing A2A Agents via MCP server resources.
Each Agent in the mesh would be able to discover other available Agents by connecting to a dedicated MCP Server via a MCP Client and browsing the resource catalogue. The suggestion is to expose Agent Cards through these MCP resources.
Once discovered, Agents would continue communication between each other utilising A2A protocol.
Having said this, if we move towards Agent discovery via a global index, the importance of MCP here would also decrease or it could even disappear.
Could A2A eat up MCP long term?
So is MCP at risk of fading into irrelevance?
For quite some time already there was a clear need for a medium that would connect swarms of Agents unleashed to the world between each other and to other legacy systems. There were talks about headless browsers, but it does seem like these open communication protocols will actually be the way forward. I believe that this is also where the talks about MCP being the new http moment (over-exaggerated?) were coming from.
The following thoughts are based on some assumptions:
Open communication protocols will integrate the Agents of the new world.
There is benefit in being behind the leading protocol.
Both protocols will continue to evolve and potentially expand the boundaries of responsibility.
Similarities in MCP and A2A.
There are some clear similarities in bots protocols and a user could choose how to model their Agentic applications and expose them to the world in multiple ways.
With MCP skyrocketing in popularity it is becoming a norm for companies to ship MCP servers as part of their offerings so that developers can seamlessly integrate context from these platform into their own LLM based applications.
However, MCP is facing some issues in adoption.
One of the biggest downsides of the protocol is the lack in security and authentication. You do need to tinker around the basic implementation to expose a remote MCP server securely.
Tools can describe anything, including other Agents. Unfortunately, MCP does not implement any primitives that facilitate proper communication between Agents via tools (state/context exchange, long-running task support etc).
This is where Google might have found a wedge to enter the protocol wars with A2A by fixing the above.
I can not shake off the feeling that Anthropic had bigger plans for MCP than it’s current state. Including the interconnection of multiple Agents together. Now, the door to expand into this are might be closed due to emergence of A2A.
What is really important long term?
If we think long term, how will the Agentic world really be modelled?
Companies expose their data assets to be used by Agents.
Companies expose Agents that can return data or perform actions.
Companies ARE Agents that other Agents can interact with.
I am betting on the movement towards the last option.
If the assumption holds, the real power is in the hands of the protocol that controls remote inter-Agent communication protocol.
Even short term, assuming the second point would be a default option for newly emerging companies, if one chooses to expose their data via an Agent, A2A is a clear winner.
Having said this, will MCP remain as the protocol to stitch new kinds of applications with legacy systems and will fade into irrelevance once Agents take over? Who knows, lets wait and see.
But if that happens, guess which player in the industry I am betting on :)
Wrapping up.
We are living in exciting times. The way how the new type of Agentic application will be connected at scale is being defined before our eyes.
A2A may be the new kid on the block, but it’s quickly shaping up to be the leader in inter-Agent communication. While MCP brought structure to how LLMs integrate context, A2A is solving for what MCP lacks: security, state management, and real-time collaboration. Will A2A eat MCP? Who knows.
While official stance is that the two protocols are solving completely different problems, there are potential overlaps and one could expect the protocols to also be expanded in scope.
If the future is Agentic, and companies begin exposing Agents rather than just tools or data, the protocol that enables seamless inter-Agent interaction might just be the winner. Right now, it seems like A2A might be choosing the right moves.
This is it for today, hope to see you in the next episode!
They're complementary — but the stack isn't complete with just MCP + A2A. MCP handles agent→tool, A2A handles agent→agent communication. Two pieces still missing: a collaboration layer (shared memory, task coordination, oversight) and a trust layer (who's allowed to do what, with scores that decay if not maintained). Without those, you've got agents that can talk to tools and each other but can't build reliable working relationships. The full stack is MCP → A2A → AACP → ATP → AG-UI.
I believe MCP for A2A could be what is Persistence Layer for Service Layer in a 3-Tiered application.