stdio vs SSE transport question

[xyc]

I'm looking at integrating MCP with a desktop app. The spec mentions "Clients SHOULD support stdio whenever possible.". The server examples seem to be mostly stdio as well. In the context of a sandboxed desktop app, it's often not practical to launch a server as subprocess because:

• sandbox restrictions of executing binaries
• needing to bundle binary leads to a larger installation size

Would it be reasonable to relax this restriction and provide both SSE/stdio for the default server examples?

[jspahrsummers]

Totally understand where you're coming from. Unfortunately, SSE has its own problems, like opening a socket that is then exposed to the internet. Even if bound to 127.0.0.1, your browser (for example)—and therefore any website—could attempt to initiate connections to it, which we feel is an unacceptable security risk.

Instead, perhaps we could consider transports implementing other types of IPC. Streaming to/from files would probably be the most cross-platform thing, but there are other, platform-specific options too. Would be happy to review contributions if anyone wants to take a stab at adding transports like this into the SDKs!

[xyc]

Thanks! Understand that there are security concerns involved, and additional transport support seems to be good for specific platform use cases. (like XPC for macOS).

Even if bound to 127.0.0.1, your browser (for example)—and therefore any website—could attempt to initiate connections to it

I'd imagine other websites can't access it because of the cross-origin restrictions? Of course privileged apps (VS Code/terminal comes to thought) can access the loopback address but such apps can also access the stdio servers.