171–180 of 293 posts
What “agents” need is not a protocol for operating, they need a protocol for discovery and addressability. How do I find someone’s agent? How do I talk to it and verify its identity? Once I’ve done that, it can just be a normal chat interface for all I care.
Earlier quoted context omitted.
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.
at some level, sure, but I can no longer put +++ATH0 into my comment and have it hang up your connection, so it's worth some effort to prevent the problem.
At least this uses existing standards, which was my biggest gripe with MCP. That said - protocol whiplash. And it might get worse.
Earlier quoted context omitted.
I was in the same boat in regards to trying to find the actual JSON that was going over the wire. I ended up using Charles to capture all the network requests. I haven't finished the post yet, but if you want to see the actual JSON I have all of the request and responses here https://www.catiemcp.com/blog/mcp-transport-layer/
I had never heard of charles ... ( https://www.charlesproxy.com/ ) I basically wrote a simple version of it 20 years ago ( https://github.com/kristopolous/proxy ) that I use because back then, this didn't exist ... I need to remember to toss my old tools aside
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/
https://modelcontextprotocol.io/specification/2025-03-26/ser...
“ For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.
Applications SHOULD:
Provide UI that makes clear which tools are being exposed to the AI model Insert clear visual indicators when tools are invoked Present confirmation prompts to the user for operations, to ensure a human is in the loop”
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 reasona…
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.
Looking at partners of this effort, I wonder what problems does A2A create to serve as a solution.
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/
From the spec: https://modelcontextprotocol.io/specification/2025-03-26/ser... “ For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations. Applications SHOULD: Provide UI that makes clear which tools are being exposed to the AI model Insert clear visual indicators when tools are invoked Present confirmation prompts to the user for operations, to ensure a hu…