upvote
Is stdio being deprecated? I couldn't tell from this page
reply
The prose on the page is very unclear. My best interpretation is that they want to continue supporting stdio but that they don’t want it to be its own special protocol. The obvious way to do that would be to speak ordinary HTTP (version 1.1? 2?) over stdio and to use the MCP-over-HTTP protocol over the resulting HTTP transport.

This would be more complex to implement for a simple server, but it’s not exactly difficult.

reply
Not everyone is on board with the idea of HTTP being the exclusive universal IPC bus.
reply
I’m not really a fan. But if you’re building a protocol that needs to map to HTTP anyway, then maybe using the HTTP binding everywhere is not totally awful.

In the flip side: I’m currently designing an AI-adjacent protocol, and it will be able to map to WebTransport, but I don’t plan to define non-WebTransport HTTP bindings unless a very compelling reason appears. The main implementations will not use HTTP at all :)

reply
> if you’re building a protocol that needs to map to HTTP anyway

I don't think there is any guarantee that HTTP will always be involved. For example I might be calling a local LLM via CLI/script on a server with a stdio MCP connector that just runs other CLI commands, and never sends any HTTP traffic.

reply
Right. But there is a lot of real-world usage of MCP-over-HTTP-over-the-Internet, and a lot of “harnesses” want to support that use case, so they’re stuck either implementing the HTTP-based protocol or using a shim.
reply
Would you prefer gRPC, thrift, avro, etc... ?
reply
Those are mostly at a different layer. You can speak Thrift or Avro or Protobuf over stdio or HTTP or TCP or carrier pigeon.

gRPC spans layers, and it uses HTTP in a more intrusive way than even MCP does — it expects to own the entire URL space at the IP/port in question. Using gRPC in a nontrivial way for MCP would be fairly heavy-weight: you would probably need to set up reflection and figure out how to bind all the MCP calls to it unless you just use it as a tunnel.

reply
reply
Wow, that looks like a huge mess.
reply
I would prefer a core transport agnostic protocol, and then see MCP-over-HTTP being a spec on top of that.
reply
Count me as not on board
reply
The real disaster was making it stateful. Need to get some adults in the room.
reply