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.
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?
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.
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.
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
Especially since the cost in some (most?) cases won’t be from the MCP server but from the LLM using it
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.