5 ms·

OpenAPI (or its Swagger predecessor) or Proto (I assume by this you mean protobuf?) don't cover what MCP does. It could have layered over them instead of using

OpenAPI (or its Swagger predecessor) or Proto (I assume by this you mean protobuf?) don't cover what MCP does. It could have layered over them instead of using JSON-RPC, but I don't see any strong reason why they would be better than JSON-RPC as the basis (Swagger has communication assumptions that don't work well with MCP's local use case; protobuf doesn't cover communication at all and would require additional consideration in the protocol layered over it.) You'd still need basically the entire existing MCP spec to cover the use cases if it replaced JSON-RPC with Swagger or protobuf, plus additional material to cover the gaps and complications that that switch would involve.

vineyardmike 1y ago
Proto has a full associated spec (gRPC) on communication protocols and structured definitions for them. MCP could easily have built upon these and gotten a lot “for free”. Generally gRPC is better than JsonRPC (see below). I agree that swagger leaves a lot unplanned. I disagree about the local use case because (1) we could just run local HTTP servers easily and (2) I frankly assume the future of MCP is mostly remote. Returning back to JSON-RPC, it’s a poorly executed RPC protocol. Here is an excellent HackerNews thread on it, but the TLDR is parsing JSON is expensive and complex, we have tons of tools (eg load balancers) that make modern services, and making those tools parse json is very expensive. Many people in the below thread mention alternative ways to implement J-RPC but that depends on new clients. https://news.ycombinator.com/item?id=34211796 https://news.ycombinator.com/item?id=34211796
SahAssar 1y ago
I don't understand what MCP gives that a REST API with a OpenAPI definition would not give?
- whoknowsidont 1y ago
  Not much, really. A lot of LLM models need system prompts or fine-tuning to reliably use MCP; (though to be clear you don't NEED to do either of those things, it just dramatically increases the reliability of the LLM) It's amusing to watch people refer to MCP as a set of tools, or a framework, or an SDK you can invoke, or something or other across a wide range of forums.It's just a standard. A convention. Calling it a protocol is a stretch as well. But there's no meat to it, really. If you just used Rest API's, you'd need to create little "tools" (say, another executable) locally that the LLM can invoke that can call those API's. MCP standardizes what those tools should act like and their overall lifecycle model. The references to it being like USB are also quite frankly absurd and delusional. But that's the caliber of developer we're dealing with today.
- owebmaster 1y ago
  Lots of people get this confused but MCP has other transports, not only StreamableHTTP but also IO, In Memory, WebSockets. If it was based on OpenAPI, servers created using transports that are not HTTP would need to implement a http server.
  - adregan 1y ago
    There are only 2 transports in the current spec[0] though. WebSockets would be welcome but aren't a part of the spec. 0: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports https://modelcontextprotocol.io/specification/2025-06-18/bas...
deleted 1y ago
[deleted]

vineyardmike 1y ago

Proto has a full associated spec (gRPC) on communication protocols and structured definitions for them. MCP could easily have built upon these and gotten a lot “for free”. Generally gRPC is better than JsonRPC (see below). I agree that swagger leaves a lot unplanned. I disagree about the local use case because (1) we could just run local HTTP servers easily and (2) I frankly assume the future of MCP is mostly remote. Returning back to JSON-RPC, it’s a poorly executed RPC protocol. Here is an excellent HackerNews thread on it, but the TLDR is parsing JSON is expensive and complex, we have tons of tools (eg load balancers) that make modern services, and making those tools parse json is very expensive. Many people in the below thread mention alternative ways to implement J-RPC but that depends on new clients. https://news.ycombinator.com/item?id=34211796 https://news.ycombinator.com/item?id=34211796

SahAssar 1y ago

I don't understand what MCP gives that a REST API with a OpenAPI definition would not give?

whoknowsidont 1y ago
Not much, really. A lot of LLM models need system prompts or fine-tuning to reliably use MCP; (though to be clear you don't NEED to do either of those things, it just dramatically increases the reliability of the LLM) It's amusing to watch people refer to MCP as a set of tools, or a framework, or an SDK you can invoke, or something or other across a wide range of forums.It's just a standard. A convention. Calling it a protocol is a stretch as well. But there's no meat to it, really. If you just used Rest API's, you'd need to create little "tools" (say, another executable) locally that the LLM can invoke that can call those API's. MCP standardizes what those tools should act like and their overall lifecycle model. The references to it being like USB are also quite frankly absurd and delusional. But that's the caliber of developer we're dealing with today.
owebmaster 1y ago
Lots of people get this confused but MCP has other transports, not only StreamableHTTP but also IO, In Memory, WebSockets. If it was based on OpenAPI, servers created using transports that are not HTTP would need to implement a http server.
- adregan 1y ago
  There are only 2 transports in the current spec[0] though. WebSockets would be welcome but aren't a part of the spec. 0: https://modelcontextprotocol.io/specification/2025-06-18/basic/transports https://modelcontextprotocol.io/specification/2025-06-18/bas...

deleted 1y ago

[deleted]