The consensus around here seems to be that the protocol itself is fine, but the transport is controversial.
Personally, even the stdio transport feels suboptimal. I mostly write python and startup time for a new process is nontrivial. Starting a new process for each request doesn't feel right. It works ok, and I'll admit that there's a certain elegance to it. It would be more practical if I were using a statically compiled language.
As far as the SSE / "Streamable HTTP" / websockets discussion, I think it's funny that there is all this controversy over how to implement sockets. I get that this is where we are, because the modern internet only supports a few protocols, but a the network level you can literally just open up a socket and send newline delimited JSON-RPC messages in both directions at full duplex. So simple and no one even thinks about it. Why not support the lowest level primitive first? There are many battle tested solutions for exposing sockets over higher level protocols, websockets being one of them. I like the Unix Philosophy.
Thinking further, the main issue with just using TCP is the namespace. It's similar to when you have a bunch of webservers and nginx or whatever takes care of the routing. I use domain sockets for that. People often just pick a random port number, which works fine too as long as you register it with the gateway. This is all really new, and I'm glad that the creators, David and Justin, had the foresight to have a clean separation between transport and protocol. We'll figure this out.
> Starting a new process for each request doesn't feel right.
I think there is a misunderstanding of how stdio works. The process can be long running and receive requests via stdio at any time. No need to start one for each request.
Sure, but that is not what I'm seeing in FastMCP proxy mode, and it can only talk with the parent process. You make a good point though, stdio is similar to tcp sockets and cross-platform without namespace issues, but can only support one client per process. I could use socat if I want it to talk sockets.
Personally, even the stdio transport feels suboptimal. I mostly write python and startup time for a new process is nontrivial. Starting a new process for each request doesn't feel right. It works ok, and I'll admit that there's a certain elegance to it. It would be more practical if I were using a statically compiled language.
As far as the SSE / "Streamable HTTP" / websockets discussion, I think it's funny that there is all this controversy over how to implement sockets. I get that this is where we are, because the modern internet only supports a few protocols, but a the network level you can literally just open up a socket and send newline delimited JSON-RPC messages in both directions at full duplex. So simple and no one even thinks about it. Why not support the lowest level primitive first? There are many battle tested solutions for exposing sockets over higher level protocols, websockets being one of them. I like the Unix Philosophy.
Thinking further, the main issue with just using TCP is the namespace. It's similar to when you have a bunch of webservers and nginx or whatever takes care of the routing. I use domain sockets for that. People often just pick a random port number, which works fine too as long as you register it with the gateway. This is all really new, and I'm glad that the creators, David and Justin, had the foresight to have a clean separation between transport and protocol. We'll figure this out.