3 ms·

> I can’t really see anything that is made better by MCP over OpenAPI Well it’s transport agnostic, for one. I think a big part of it is defining a stateful c

by dartos 2y ago

> I can’t really see anything that is made better by MCP over OpenAPI Well it’s transport agnostic, for one. I think a big part of it is defining a stateful connection and codifying the concepts of prompts and tools. Another issue with OpenAPI / swagger is that you still need to create a client per API, but with MCP it’s all uniform.

nsonha 2y ago
I feel like we should have transport agnostic RPC by now, GRPC? And MCP is stateless too. And you don't have to create a client per API, it's up to implementation.
- dartos 2y ago
  I think MCP is a layer higher than grpc. MCP can be implemented on gRPC Mcp is definitely not stateless. It’s explicitly stateful… See the 2nd bullet where it says “stateful connections” [1] And I was saying that with OpenAPI, you need a client per API, or at least a series of http api calls. 1. https://spec.modelcontextprotocol.io/specification/2025-03-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2...
  - nsonha 2y ago
    Higher in what way? But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.
    - dartos 2y ago
      “That document” is the MCP spec. What is says _is_ MCP, regardless of your understanding of it. It’s not a “mandate” it’s a specification for how the protocol works. If the connection isn’t stateful, then it isn’t adhering to the specification. I mean also like… how is it stateless? For both example transports (stdio and SSE) a connection must be maintained. ANY connection must be initialized via an MCP message and both server and client must negotiate capabilities. Those capabilities must be honored through the entire lifetime of the connection. That alone is state. I suggest you read the spec…
    - dartos 2y ago
      Also > Higher in what way? Higher as in at a higher level in the network stack (not exactly, I don’t think, but lower on the same level) Higher as in you can implement MCP on top of grpc. You can’t implement grpc in mcp, that doesn’t make sense, because grpc is at a lower level, so to speak, in the network stack.
- Spivak 2y ago
  Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1]. https://spec.modelcontextprotocol.io/specification/2025-03-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2... * JSON-RPC message format * Stateful connections * Server and client capability negotiation There's a draft [1] maybe about resolving this. https://github.com/modelcontextprotocol/specification/pull/206 https://github.com/modelcontextprotocol/specification/pull/2...
  - dartos 2y ago
    https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/ https://spec.modelcontextprotocol.io/specification/2025-03-2... They mention stdio specifically under the transport section of the spec. Most protocols are transport agnostic, but http APIs tend to require HTTP methods. Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around. If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly. To get the full features of the protocol (like notifications) a stateful connection would still be required.
slt2021 2y ago
transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy. so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds). I really wish OpenAI just embraced OpenAPI and that would have instantly gained millions of existing sites available to ChatGPT with zero code change.
- sethaurus 2y ago
  It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.
  - Xelynega 2y ago
    HTTP also works locally(over local files including stdin/stdout), not just remotely.

by dartos 2y ago

nsonha 2y ago

I feel like we should have transport agnostic RPC by now, GRPC? And MCP is stateless too. And you don't have to create a client per API, it's up to implementation.

dartos 2y ago
I think MCP is a layer higher than grpc. MCP can be implemented on gRPC Mcp is definitely not stateless. It’s explicitly stateful… See the 2nd bullet where it says “stateful connections” [1] And I was saying that with OpenAPI, you need a client per API, or at least a series of http api calls. 1. https://spec.modelcontextprotocol.io/specification/2025-03-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2...
- nsonha 2y ago
  Higher in what way? But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.
  - dartos 2y ago
    “That document” is the MCP spec. What is says _is_ MCP, regardless of your understanding of it. It’s not a “mandate” it’s a specification for how the protocol works. If the connection isn’t stateful, then it isn’t adhering to the specification. I mean also like… how is it stateless? For both example transports (stdio and SSE) a connection must be maintained. ANY connection must be initialized via an MCP message and both server and client must negotiate capabilities. Those capabilities must be honored through the entire lifetime of the connection. That alone is state. I suggest you read the spec…
  - dartos 2y ago
    Also > Higher in what way? Higher as in at a higher level in the network stack (not exactly, I don’t think, but lower on the same level) Higher as in you can implement MCP on top of grpc. You can’t implement grpc in mcp, that doesn’t make sense, because grpc is at a lower level, so to speak, in the network stack.
Spivak 2y ago
Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1]. https://spec.modelcontextprotocol.io/specification/2025-03-26/#base-protocol https://spec.modelcontextprotocol.io/specification/2025-03-2... * JSON-RPC message format * Stateful connections * Server and client capability negotiation There's a draft [1] maybe about resolving this. https://github.com/modelcontextprotocol/specification/pull/206 https://github.com/modelcontextprotocol/specification/pull/2...
- dartos 2y ago
  https://spec.modelcontextprotocol.io/specification/2025-03-26/basic/transports/ https://spec.modelcontextprotocol.io/specification/2025-03-2... They mention stdio specifically under the transport section of the spec. Most protocols are transport agnostic, but http APIs tend to require HTTP methods. Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around. If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly. To get the full features of the protocol (like notifications) a stateful connection would still be required.

slt2021 2y ago

transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy. so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds). I really wish OpenAI just embraced OpenAPI and that would have instantly gained millions of existing sites available to ChatGPT with zero code change.

sethaurus 2y ago
It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.
- Xelynega 2y ago
  HTTP also works locally(over local files including stdin/stdout), not just remotely.