OK, I’ve read the website, the spec, and JavaScript and python clients and servers. Here’s a quick initial reaction.
1. This is in the “embrace and extend” type area vis-a-vis MCP — if you implemented A2A for a project I don’t think you’d need to implement MCP. That said, if you have an MCP server, you could add a thin layer for A2A compliance.
2. This hits and improves on a bunch of pain points for MCP, with reasonable relatively light weight answers — it specs out how in-band and out-of-band data should get passed around, it has a sane (token based largely) approach to security for function calling, it has thought about discovery and security with a simple reliance on the DNS security layer, for instance.
3. The full UI demos imagine significantly more capable clients - ones that can at least implement Iframes - and reconnect to lost streaming connections, among other things. It’s not clear to me that there’s any UI negotiation baked into this right now, and it’s not clear to me what the vision is for non-HTML-capable clients. That said, they publish clients that are text-only in the example repo. It may be an area that isn’t fully fleshed out yet, or there may be a simple answer I didn’t see immediately.
Upshot - if you’re building an MCP server right now, great —- you should read the A2A spec for a roadmap on some things you’ll care about at some point, like auth and out of band data delivery.
If you’re thinking about building an MCP server, I’m not sure I’d move ahead on vanilla MCP - I think the A2A spec is better specified, and if for some reason A2A doesn’t take off, it will only be because MCP has added support for a couple of these key pain points — it should be relatively easy to migrate.
I think any mid-size or better tool calling LLM should be able to get A2A capability json and figure out what tool to call, btw.
One last thing - I appreciate the GOOG team here for their relatively clear documentation and explanation. The MCP site has always felt a little hard to understand.
Second last thing: notably, no openAI or Anthropic support here. Let’s hope we’re not in xkcd 927 land.
Upshot: I’d think of this as a sane superset of MCP and I will probably try it out for a project or two based on the documentation quality. Worst case, writing a shim for an exact MCP capable server is a) probably not a big deal, and b) will probably be on GitHub this week or so.
> Worst case, writing a shim for an exact MCP capable server is a) probably not a big deal, and b) will probably be on GitHub this week or so.
That sounds exactly like the kind of thing I would outsource to an LLM. I think people over think the need for protocols here. Most AIs are already pretty good at figuring out how to plumb relatively simple things together if they have some sort of documented interface. What the interface is doesn't really matter that much. I've had good results just letting it work off openapi descriptions. Or generating those from server source code. It's not that hard.
In any case, MCP is basically glorified remote procedure calls for LLMs. And then Google adds a bit of probably necessary complexity on top of that (auth sounds important if we're connecting with third party systems). Long lived tasks and out of band data exchange sounds like it could be useful.
For me the big picture and takeaway is that a future of AIs using tools, some of which may be other AIs using tools communicating with each other asynchronously is going to be a thing. Probably rather soon. Like this year.
That puts pressure on people to expose capabilities of their SAAS services in an easily digestible form to external agents. That's going to generate a lot of short term demand from various companies. Most of whom are not really up to speed with any of this. Great times to be a consultant but beware the complexity that design by committee generates.
I largely agree with most of this. My only concern is that the spec is a bit underspecified.
For example I wish they'd specify the date format more tightly - unix timestamp, some specific ISO format, precision. Which is it?
The sessionID is not specified. You can put all sorts of crazy stuff in there, and people will. Not even a finite length is required. Just pick some UUID format already, or specify it has to be an incrementing integer.
Define some field lenght limits that can be found on the model card - e.g. how long can the description field be before you get an error? Might be relevant to context sizes. If you don't you're going to have buffer overflow issues everywhere because vibe coders will never think of that.
Authentication methods are specified as "Open API Authentication formats, but can be extended to another protocol supported by both client and server". That's a recipe for a bunch of byzantine Enterprize monstrosities to rear their ugly heads. Just pick one or two and be done with it.
The lesson of past protocols is that if you don't tightly specify things you're going to wind up with a bunch of nasty little incompatibilities and "extensions" which will fragment the ecosystem. Not to mention security issues. I guess on the whole I'm against Postel's Law on this.
Thank you for the feedback? Would you consider writing up an issue on our github with some more specifics? https://github.com/google/a2a
A2A is being developed in the open with the community. You are finding some early details that we are looking into and will be addressing. We have many partners who will be contributing and want this to be a truly open, collaborative endeavor. We acknowledge this is a little different than dropping a polished '1.0' version in github on day 1. But that is intentional :)
I think MCP could totally evolve to support the same features A2A offers. Most of what A2A does feels like it could be layered onto MCP with some extensions — especially around auth, discovery, and out-of-band handling. If MCP maintainers are paying attention, they'd probably just adopt the good bits. Wouldn’t be surprised to see some convergence.
Hi there - I work on a2a. Thanks for the reaction - lots of good points here. We really do see a2a as different and complementary to MCP. I personally am working on both and see them in very different contexts.
I see MCP as vital when building an agent. An agent is an LLM with data, resources, tools, and services. However, our customers are building or purchasing agents from other providers - e.g. purchasing "HR Agent", "Bank Account Agent", "Photo Editor Agent", etc. All of these agents are closed systems and have access to private data, APIs, etc. There needs to be a way for my agent to work with these other agents when a tool is not enough.
Other comments you have are spot on - the current specification and samples are early. We are working on many more advanced examples and official SDKs and client/servers. We're working with partners, other Google teams, and framework providers to turn this into a stable standard. We're doing it in the open - so there are things that are missing because (a) its early and (b) we want partners and the community to bring features to the table.
tldr - this is NOT done. We want your feedback and sincerely appreciate it!
1. This is in the “embrace and extend” type area vis-a-vis MCP — if you implemented A2A for a project I don’t think you’d need to implement MCP. That said, if you have an MCP server, you could add a thin layer for A2A compliance.
2. This hits and improves on a bunch of pain points for MCP, with reasonable relatively light weight answers — it specs out how in-band and out-of-band data should get passed around, it has a sane (token based largely) approach to security for function calling, it has thought about discovery and security with a simple reliance on the DNS security layer, for instance.
3. The full UI demos imagine significantly more capable clients - ones that can at least implement Iframes - and reconnect to lost streaming connections, among other things. It’s not clear to me that there’s any UI negotiation baked into this right now, and it’s not clear to me what the vision is for non-HTML-capable clients. That said, they publish clients that are text-only in the example repo. It may be an area that isn’t fully fleshed out yet, or there may be a simple answer I didn’t see immediately.
Upshot - if you’re building an MCP server right now, great —- you should read the A2A spec for a roadmap on some things you’ll care about at some point, like auth and out of band data delivery.
If you’re thinking about building an MCP server, I’m not sure I’d move ahead on vanilla MCP - I think the A2A spec is better specified, and if for some reason A2A doesn’t take off, it will only be because MCP has added support for a couple of these key pain points — it should be relatively easy to migrate.
I think any mid-size or better tool calling LLM should be able to get A2A capability json and figure out what tool to call, btw.
One last thing - I appreciate the GOOG team here for their relatively clear documentation and explanation. The MCP site has always felt a little hard to understand.
Second last thing: notably, no openAI or Anthropic support here. Let’s hope we’re not in xkcd 927 land.
Upshot: I’d think of this as a sane superset of MCP and I will probably try it out for a project or two based on the documentation quality. Worst case, writing a shim for an exact MCP capable server is a) probably not a big deal, and b) will probably be on GitHub this week or so.