51–60 of 293 posts
A2A is for communication between the agents. MCP is how agent communicate with its tools.
Important aspect of A2A, is that it has a notion of tasks, task rediness, and etc. E.g. you can give it a task and expect completely in few days, and get notified via webhook or polling it.
For the end users for sure A2A will cause a big confusing, and can replace a lot of current MCP usage.
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…
from fastmcp import FastMCP
mcp = FastMCP("Demo ")
@mcp.tool()
def add(a: int, b: int) -> int:
"""Add two numbers"""
return a + b
Do you know real use cases of agents? Actually used and that have been using for a while. Not just for curiosity. I read about them only for hypothetical scenarios. Is it a real thing?
That depends very much on which of the dozen+ definitions of "agent" you are using.
https://www.anthropic.com/engineering/building-effective-age...
With all this agents talks, maybe I should dust off my old Tcl books on Agent Tcl. https://digitalcommons.dartmouth.edu/dissertations/62/
That looks interesting from abstract. Can you please explain how these two can be interconnected ?
As far as I can remember, never really left the research lab, with a few books and papers published on the matter.
Everything old is new again.
MCP - exposes prompts, resources and tools to a host, who can do whatever they like
A2A - exposes capability discovery, tasks, collaboration?/chat?, user experience discussions (can we embed an image or or a website?).
High-level it makes sense to agree on these concepts. I just wonder if we really need a fully specified protocol? Can't we just have a set of best practices around API endpoints/functions? Like, imo we could just keep using Rest APIs and have a convention that an agent exposes endpoints like /capabilities, /task_status ...
I have similar thoughts around MCP. We could just have the convention to have an API endpoint called /prompts and keep using rest apis?
Not sure what I am missing.
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/
Let's start with fixing the examples...
This doesn't say anything about the protocol other than what would be obvious (a JSON card describing the agent's schema) and that it will use http (such a safe, but low-effort bet). I was hoping for more, but with so many cooks in the kitchen, I guess I'm not surprised.
The way they're framing this attempts to stave off disintermediation, which is the real threat.
Do you know real use cases of agents? Actually used and that have been using for a while. Not just for curiosity. I read about them only for hypothetical scenarios. Is it a real thing?
The one that will win — will be the one that gives devs the confidence to run in full “yolo/autonomous” mode. That’s the future.
on it's face this kind of seems dumb. aren't agents supposed to be adaptable enough to handle any protocol?
1. Agents don't know the APIs. This is a way for you to declare them. 2. You get to decide what functionality you want to expose agents to. 3. An API enables reliable tool use.