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.

[Madd0g]

Sorry, not sure if this is the best place to ask about SSE - I'm wondering if there's a way of making a tool that streams back tokens?

[dsp-ant]

There is currently no streaming in MCP. If we understand the set of usercases better, we can consider adding it. I would suggest starting a new discussion on streaming.

[Mehdi-Bl]

But does Claude Desktop suppse SSE?

I understand the concer over security. Could be leverage with an Auth token added in config + https, and it's the MCP server side.

So, the quest is how to hook Claude Desktop with SSE?

As Stdio indeed secure the exchange but makes it 1:1 relation between client:server, while SSE could allow access to central MCP server, wit authentification, that can leverage more data/capabilities.

Thanks for your clarification.

[xyc]

Just discovered https://github.com/supercorp-ai/supergateway it wraps an SSE layer over stdio transport. For sandboxed apps users can use sse servers that they launch on their own (that runs through the gateway).

[Mehdi-Bl]

That's not complicated to do for an MCP server.
Main issue is Claude desktop seem only suppport stdio. To connect to SSE server that meast we need to have stdio to SSE (client ) forwared to connect the facing SSE server.