Replies: 4 comments 5 replies
|
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 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! |
|
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).
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. |
|
Also interested in this. Did the MCP team consider using an http call to an endpoint and then upgrading it to a websocket? This would allow switching to a bi-directional websocket and the initial call could be authorized. This avoids leaving an open-ended SSE socket open and could still honor the MCP spec's emphasis on JSON-RPC for transports. I have a cloud app and requiring some desktop-installed client seems both impractical for our users and brings its own set "security" concerns. |
|
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? |
|
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. |
|
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. |
|
At the moment, Claude Desktop doesn't support SSE. However, you can use this proxy: https://github.com/boilingdata/mcp-server-and-gw |
|
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). |
|
That's not complicated to do for an MCP server. |
Uh oh!
There was an error while loading. Please reload this page.
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:
Would it be reasonable to relax this restriction and provide both SSE/stdio for the default server examples?
All reactions