Comparing with Google's Agent2Agent (A2A) Protocol

[richardblythman]

Pre-submission Checklist

• I have verified that this discussion would not be more appropriate as an issue in a specific repository
• I have searched existing discussions to avoid duplicates

Discussion Topic

Google announced the Agent2Agent (A2A) Protocol today. They describe it as complementary to MCP, but specify MCP as mainly being used to provide helpful tools and context to agents. We've sometimes heard about the scope of MCP being larger than that e.g. use cases involving agents and agent orchestrators as MCP servers. Also, there are discussions on this GH org for topics like statelessness (recently added to the spec) service discovery, and authentication, which seem to overlap somewhat with A2A.

This announcement feels like an important moment to clarify and explore the relationship between A2A and MCP, both practically and conceptually. In that spirit, I’d love to open a discussion about how these protocols intersect and how we might think about their respective roles as the ecosystem evolves.

Potential talking points:

1. Is MCP limited to tools, or can it be used to expose full agents?: Some teams have begun experimenting with deploying agent-like services as MCP servers — including planners, orchestrators, and multi-modal capabilities. Is this a supported direction? How do we draw the line between a “tool” and an “agent” in the MCP model?
2. Statelessness in A2A vs. MCP: How does A2A's stateless approach compare with MCP's upcoming statelessness recently added to the spec?
3. Service discovery: How does A2A's agent.json complement or overlap with well-known/mcp?

[richardblythman]

4. Multi-turn Conversations: MCP is bidirectional but in a limited and structured way, whereas A2A is designed for peer-level agent communication. Should MCP add support for bidirectional multi turn conversations?

[puchengy]

IMHO, A2A and MCP are actually overlapped protocols. It does not seem clear to me the real differentiation among them.

[grll]

Yes I have the same opinion at the moment, I trully don't understand what A2A is bringing that is not achievable with MCP in particular when looking at the picture they provide for MCP usage and the examples provided. Also looking at the protocol itself it's all very similar isn't it?

Let me develop a bit my though here:

When I look at this picture:

For me it look like the MCP server seating in front of the "Agent" which actually is a group of "sub-agents", is leveraged here only for resources for an MCP client to discover "Agent Card". Which means that you would have an MCP server running on one end to expose the AgentCard and an MCP Client on the other end probably on what A2A call the "host" doing the discovery (receiving the Agent Card) and then separetly initiating the A2A protocol / communication for triggering the work with each "sub-agents"...

If my understanding is correct the greyed arrow in this picture is only virtual in that "sub-agents" do not communicate directly between each other, but are more orchestrated / coordinated by the A2A host via the A2A Protocol.

Now if you already so far as having an MCP server for the "agent" and an MCP client for the "host", why don't you directly use MCP to perform the rest of the communication? Why not use the rest of the functionality of MCP? For example we could expose all A2A capabilities as MCP tools? Is there really some specific things that we can't do with MCP that A2A is solving?

[ukstv]

Not sure if everyone is invited here, but I’ll chime in anyway. I see two key differences worth pointing out.

The first is where the LLM sits. A2A assumes the remote peer is LLM-enabled. In contrast, an MCP server typically relies on the caller’s LLM to interpret and drive the interaction.

The second is discovery, which feels more like a matter of convention than a fundamental protocol gap. If we introduced something like an mcp.json static file to advertise tools, resources, and which tool calls represent agentic behaviors, that would effectively mirror what AgentCard provides.

As for bidirectionality: you can do A2A-style back-and-forth using MCP by having a tool call trigger a follow-up request from server to client. There might be value in agreeing on some conventions around notifications/requests schema, but technically, this pattern is already viable.

[siwachabhi]

Hi All, we have been having similar discussion in hosting group discord and captured key differences here: https://docs.google.com/document/d/18aW0P38h14ccJTkN-irhy2NVdG-_V_Oe7WblnAiKKGM/edit?tab=t.0#heading=h.kvf97tlsh3d2.

Its hard to differentiate between agents and tools at this point. Partial chunk streaming, Async tool execution, structured output, are few things MCP is missing, but looks like anyway a good idea to capture in MCP. modelcontextprotocol/modelcontextprotocol#97, modelcontextprotocol/modelcontextprotocol#314

A discussion that is still open is if tools can do back and forth/multi-turn with caller, some of us believe similar to workflows this should be an acceptable pattern and captured as hint on a tool. Else this will need to be defined as a new primitive.

[000-000-000-000-000]

related: modelcontextprotocol/modelcontextprotocol#330

[greg80303]

I definitely like the idea of including A2A in MCP -- doesn't seem like we need two different specs. But I don't think that agents are the same as tools. As a client of an MCP server, I like the idea of putting some constraints around what defines a "tool". The idea of tools being "traditional API calls" invokes some sense of understanding how they are implemented and, more importantly, that it is a relatively deterministic operation. Agents, on the other hand, can involve multi-turn interactions, and involve some form of non-deterministic "thinking" on the backend. I feel like these deserve the designation of separate context forms within MCP spec.

If we expand the concept of a tool too much, it could begin to blur the lines between existing forms of context. (Do we need "prompts" as a context type? Or we just have tools that happen to return prompts?)

[000-000-000-000-000]

On discord / in the 330 thread linked above we have been talking about concrete things that would enable us to distinguish between agents and tools. I dont think number of turns, or determinism will be the right criteria (see: modelcontextprotocol/modelcontextprotocol#330 (reply in thread)).

TBH i would love to see if we can distinguish tools and agents because in practice they "feel" different, but from all the conversation i wonder whether it would be better to just say "hey let's call them both tools, but tools can have different capabilities and we will let people define in tool metadata what those are". Then implementers can give much more precise info rather than "agent" or "tool" which maybe misleading. Thinking through what that info could be (and also taking some inspiration from a2a agent cards), maybe 1/ streaming supported or not 2/ push notifications supported or not 3/ stateful or not 4/ capabilities available on this tool (for a tool that is just an API maybe this is an empty dict?