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 Agent2Agent Protocol (A2A)
101–110 of 293 posts
Re: The Agent2Agent Protocol (A2A)
#102Earlier 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.
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)
#103It’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…
https://google.github.io/A2A/#/documentation?id=multi-turn-c...
Re: The Agent2Agent Protocol (A2A)
#104> 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...
Re: The Agent2Agent Protocol (A2A)
#105Earlier 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.
Re: The Agent2Agent Protocol (A2A)
#106The 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)
#107Earlier 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…
Re: The Agent2Agent Protocol (A2A)
#108I 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?
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)
#109This 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)
#110Are 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.