4 ms·
My current understanding: MCP - exposes prompts, resources and tools to a host, who can do whatever they like A2A - exposes capability discovery, tasks, colla
by zurfer 2y ago
My current understanding:
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.
- daxfohl 2y agoThat's the first step to creating a protocol. The next step is to formalize it, publish it, and get others to adopt it. That way, it's one less thing for LLMs to hallucinate on. Otherwise everyone has different conventions and LLMs start making stuff up. That's all these are.
- MattDaEskimo 2y agoEventually agents from different providers will come into play. It's important to agree on a standard for accurate interoperability. Ideally, the model providers would then build for the protocol, so the developers aren't writing spaghetti code for every small difference
- nlarew 2y ago> 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 ... To make this work at scale we all need to agree on the specific routes names, payloads, behaviors, etc. At that point we have defined a protocol (built on top of HTTP, itself a lower level protocol).