2 ms·

Looks similar to most other mid-level remote procedure call protocols, from XMLRPC to CORBA. The usual sync, async, poll, progress test problems apply. Things I

Looks similar to most other mid-level remote procedure call protocols, from XMLRPC to CORBA. The usual sync, async, poll, progress test problems apply. Things I'd expected to see and didn't: - Client to server: "tell me what you can do". This has always been hard, but in the LLM era, it could potentially work, because a textural response would work. - Similarly, being able to ask "How do I..." might be feasible now. It should be possible to talk to a new server and automatically figure out how to use it. - "How much is this going to cost me?" Plus some way to set a cost limit on a query.

Spivak 2y ago
The first one is included, you can ask for available actions as well as mcp sever feature support. Is there something else that's missing?
mgraczyk 2y ago
cost isn't part of MCP in the same way that cost isn't part of HTTP. It wouldn't really make sense to include that in the protocol, just put it in the application layer on top.
- boleary-gl 2y ago
  Especially since the cost in some (most?) cases won’t be from the MCP server but from the LLM using it
- hansvm 2y ago
  It's a little different. These are systems which are explicitly able to achieve better or worse outcomes by tuning the cost, in ways that aren't especially configurable otherwise. For an HTTP API, you can read the docs and use the small image vs large image endpoint or whatever and have a clear idea of what you're getting and for what cost. For LLMs, it would be very nice to be able to communicate about the desired and actual cost breakdowns for each sub-action.
  - mgraczyk 2y ago
    It would also be nice to do that for http for the same reason. You can also read the find Docs for your MCP, and the LLM can also read the docs
- b0b0b0b 2y ago
  Http 402: “my time to shine”
cyanydeez 2y ago
honestly, it looks like an unnecessary additional protocol to a REST API. Couldn't you just add a "LLM-description" (optional) field to any RESTAPI that provides a JSON description of how to use it? That's what it sounds like because every LLM already will have it's own "idea" of how to use a MCP interface. So why have a totally disparate thing. Just seems like i+1 syndrome with computing.

Spivak 2y ago

The first one is included, you can ask for available actions as well as mcp sever feature support. Is there something else that's missing?

mgraczyk 2y ago

cost isn't part of MCP in the same way that cost isn't part of HTTP. It wouldn't really make sense to include that in the protocol, just put it in the application layer on top.

boleary-gl 2y ago
Especially since the cost in some (most?) cases won’t be from the MCP server but from the LLM using it
hansvm 2y ago
It's a little different. These are systems which are explicitly able to achieve better or worse outcomes by tuning the cost, in ways that aren't especially configurable otherwise. For an HTTP API, you can read the docs and use the small image vs large image endpoint or whatever and have a clear idea of what you're getting and for what cost. For LLMs, it would be very nice to be able to communicate about the desired and actual cost breakdowns for each sub-action.
- mgraczyk 2y ago
  It would also be nice to do that for http for the same reason. You can also read the find Docs for your MCP, and the LLM can also read the docs
b0b0b0b 2y ago
Http 402: “my time to shine”

cyanydeez 2y ago

honestly, it looks like an unnecessary additional protocol to a REST API. Couldn't you just add a "LLM-description" (optional) field to any RESTAPI that provides a JSON description of how to use it? That's what it sounds like because every LLM already will have it's own "idea" of how to use a MCP interface. So why have a totally disparate thing. Just seems like i+1 syndrome with computing.