Live data from Hacker News

The Agent2Agent Protocol (A2A)

developers.googleblog.com

101–110 of 293 posts

Re: The Agent2Agent Protocol (A2A)

#101
post #71

Earlier quoted context omitted.

The APIs have docs. The agent can go read them and build against them.

The agent doesn't know what tools are available on your host. And searching for the documentation is slower and less reliable. It's an optimization.

the guiding promise of AI was able to figure out unstructured data. Manually crafting prompts and description examples for tools is a step orthogonal to progress. Searching for docs, great now you have 1000 tools saying they do same thing exposed to model, now we need another search on top of that?

Re: The Agent2Agent Protocol (A2A)

#102

Earlier quoted context omitted.

Agreed. At the end of the day we are talking about RPC. A named method, with known arguments, over the wire. A simple HTTP request comes to mind. But that would just be too easy. Oh wait, that is what all of these are under the hood. We are so cooked. from fastmcp import FastMCP mcp = FastMCP("Demo ") @mcp.tool() def add(a: int, b: int) -> int: """Add two numbers""" return a + b This is an example of fastmcp. Notice…

It's just another layer of abstraction so one doesn't need to think about HTTP at all, which would bring in irrelevant baggage.

To be fair, HTTP adds a layer of friendliness over TCP (POST/GET, paths, query parameters) and the servers can be so simple that it can hardly be considered irrelevant baggage.

The benefit it brings is that you can add debugging endpoints which you can use directly in a browser, you get networking with hosts and ports instead of local-only exe + stdio.

Re: The Agent2Agent Protocol (A2A)

#103
post #3

It’s frustratingly difficult to see what these (A2A and MCP) protocols actually look like. All I want is a simple example conversation that includes the actual LLM outputs used to trigger a call and the JSON that goes over the wire… maybe I’ll take some time and make a cheat-sheet. I have to say, the endorsements at the end somehow made this seem worse…

It's shown in the link below. It's kind of crazy that they have this huge corporate announcement with 50 logos for something that under the hood seems sort of arbitrary and very fragile, and is probably very sensitive to things like exact word choice and punctuation. There will be effects like bots that say "please" and "thank you" to each other getting measurably better results.

https://google.github.io/A2A/#/documentation?id=multi-turn-c...

Re: The Agent2Agent Protocol (A2A)

#104
post #42

> A2A is an open protocol that complements Anthropic's Model Context Protocol (MCP), which provides helpful tools and context to agents. A "server" sample: https://github.com/google/A2A/tree/main/samples/js/src/serve... So it looks like the point is that it keeps the connection/context open for multiple interactions vs. MCP, which is more like pure request-response?

MCP is stateful. They are currently developing stateless support. https://github.com/modelcontextprotocol/modelcontextprotocol...

Oh good to know, thanks for the clarification!

Re: The Agent2Agent Protocol (A2A)

#105
post #80
post #38

Earlier quoted context omitted.

Every decade or so we just forget that in-band signaling is a bad idea and make all the same mistakes again it seems. 1960s phone companies at least had the excuse of having to retrofit their control systems onto existing single-channel lines, and run the whole operation on roughly the processing power of a pocket calculator. What's our excuse?

Enterprise databases are filled with users usurping a field with pre/post-pending characters to mean something special to them. Even filenames have this problem due to limitations in directory trees. Inband signals will never go away.

At some level everything has to go in a single band. I don't have separate network connections to my house, I don't send separate TCP SYN packets for each "band". I don't have separate storage devices for each file on my harddrive. We multiplex the data somewhere. Yhe trick to it is that the multiplexer has to be a component, and not a distributed set of ad-hoc regexes.

Re: The Agent2Agent Protocol (A2A)

#106
Some very quick initial thoughts - the json spec has some similarities to mcp: https://google.github.io/A2A/#/documentation?id=agent-card - there's an agent card that describes capabilities that google wants websites to host at https://DOMAIN/.well-known/agent.json according to https://google.github.io/A2A/#/topics/agent_discovery so crawlers can scrape to discover agents.

The jsonrpc calls look similar-ish to mcp tool calls except the inputs and outputs look closer to the inputs/outputs from calling an LLM (ie messages, artifacts, etc.).

The JS server example that they give is interesting https://github.com/google/A2A/tree/main/samples/js/src/serve... - they're using a generator to send sse events back to the caller - a little weird to expose as the API instead of just doing what express allows you to do after setting up an sse connection (res.send / flush multiple times).

Re: The Agent2Agent Protocol (A2A)

#107
post #75

Earlier quoted context omitted.

Agreed. At the end of the day we are talking about RPC. A named method, with known arguments, over the wire. A simple HTTP request comes to mind. But that would just be too easy. Oh wait, that is what all of these are under the hood. We are so cooked. from fastmcp import FastMCP mcp = FastMCP("Demo ") @mcp.tool() def add(a: int, b: int) -> int: """Add two numbers""" return a + b This is an example of fastmcp. Notice…

Ironically, I tried to use the official "github-mcp" and failed to make it work with my company's repos, even with a properly configured token. The thing comes with a full blown server running inside a docker container. Well, I just told my llm agent to use the `gh` cli instead. It seems all those new protocols are there to re-invent wheels just to create a new ecosystem of free programs that corporations will be abl…

I feel the same way about OpenAI‘s new responses API. Under the cover of DX they‘re marketing a new default, which is we hold your state and sell it back to you.

Re: The Agent2Agent Protocol (A2A)

#108
post #99
post #19

I just published some notes on MCP security and prompt injection. MCP doesn't have security flaws in the protocol itself, but the patterns it encourage (providing LLMs with access to tools that can act on the user's behalf while they also may be exposed to text from untrusted sources) are rife for prompt injection attacks: https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/

great writeup! so what's the solution? is it only use pre-vetter "Apple Store" of known good MCP integrations from well known companies, and avoid using anything else without proper review?

yes.

This has been discussed before, but the short version is: there is no solution currently, other than only use trusted sources.

Unless there is a way beyond a flat text file to distinguish different parts of the “prompt data” so they cannot interfere with each other (and currently there is not), this idea of arbitrary content going into your prompt (which is literally what MCP does) can’t be safe.

It’s flat out impossible.

The goal of “arbitrary 3rd party content in prompt” is fundamentally incompatible with “agents able to perform privileged operations” (securely and safely, that is).

Re: The Agent2Agent Protocol (A2A)

#109
I don't totally understand why we need an additional layer of abstraction over MCP at this point. Why can't an agent just be an MCP server? What is the fundamental difference between an MCP server "tool" and an agent "capability"?

This kind of feels to me like someone at google saw how successful MCP was becoming and said "we need something like that". I feel the same way about OpenAI's Agent SDK.

I think the word "Agent" appearing in any engineering project is a tell that it's driven by marketing rather than engineers' needs.

Re: The Agent2Agent Protocol (A2A)

#110
post #63

Are we rediscovering SOA and WSDL, but this time for LLM interop instead of web services? I may be wrong, but I'm starting to wonder whether software engineering degrees should include a history subject about the rise and fall of various architectures, methodologies and patterns.

don't forget CORBA and OSGi
Post reply on HN