241–250 of 293 posts
Earlier quoted context omitted.
itd be nice if you prettified your json in the blogpost fwiw i thought the message structure was pretty clear on the docs https://modelcontextprotocol.io/docs/concepts/architecture#m...
Some (many?) people learn better from concrete examples and generalize from them.
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…
Earlier quoted context omitted.
Sort of like asking a non-deterministic human to help make changes to an existing computer system. Extends the problems of human team management to our technology systems.
Not only extends them, but compounds them because you have a non-deterministic human making changes to a non-deterministic computer system which is making changes to an existing computer system.
Earlier quoted context omitted.
Not only extends them, but compounds them because you have a non-deterministic human making changes to a non-deterministic computer system which is making changes to an existing computer system.
That's basically the problem of employing and managing people.
"If you just get out of people's way, then they'll do a good job and the right thing!" - yea, perhaps. But how much of "getting out their way" is more a product of providing meaningful ownership and compensation in the workplace? See the paragraph above. Good employees are expensive and as time marches on, their compensation will need to continue to increase at least with inflation, while the machine will likely become cheaper to operate over time as societal advances bring down the cost and complexity of operation.
How it claims to complement/differentiate from MCP here: https://google.github.io/A2A/#/topics/a2a_and_mcp Basically (google claims): MCP enables agents to use resources in a standard way. A2A enables those agents to collaborate with each other.
I suppose Google wants us to pretend that "agents" can't be "resources." MCP is already well established (Anthropic, OpenAI, Cursor, etc), so Google plastering their announcement with A2A endorsements just reeks of insecurity. I figure this A2A idea will wind up in the infamous Google graveyard within 8 months.
Earlier quoted context omitted.
even the approach that charles takes for intercepting TLS traffic is a bit old school (proxies, fake root certs etc.) - cool kids use eBPF https://mitmproxy.org/posts/local-capture/linux/
I can see how you don't need a proxy any more, but I don't see how you can bypass TLS without fake root certs, even with eBPF.
in short, you can hook calls within SSL libraries (like OpenSSL)
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/
we also recently published our approach on MCP security for mcp.run. Our "servlets" run in a sandboxed environment; this should mitigate a lot of the concerns that have been recently raised. https://docs.mcp.run/blog/2025/04/07/mcp-run-security
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/
Earlier quoted context omitted.
Take a look at the samples: https://google.github.io/A2A/#/documentation
Oh, that's really nice. I'd also like to see what syntax the LLM uses to _trigger_ these calls, and what prompt is sent to the LLM to tell it how to do that. I should probably just go read Goose's code…
Earlier quoted context omitted.
I dont fully understand. The protocol uses HTTP and has a JSON schema. But there are more specifications outside of that. How do you specify those things without a new protocol? Or is the argument that you dont need to specify those things?
REST is a protocol that uses HTTP and a JSON schema. I fail to see how they're different, they're both "these are the remote procedures you can call on me, and the required parameters, maybe some metadata of the function/parameters".
For one, REST is not RPC, despite being commonly confused for it and abused as such. The conceptual models are different. It makes more sense for an action-oriented RPC protocol to be defined as such, instead of a proper REST approach (which is going to be way too verbose), or some bastardized "RESTful" protocol that's just weirdly-structured RPC designed so people can say, "look ma', I'm using HTTP verbs, I'm doing REST".