Repository navigation
Support streamable HTTP via packages #143
Description
Activity
Accidentally made a dupe: #148
I'm inclined to say we should just add a
transportfield withinpackages. If we're uncomfortable with the security hole in the official registry API, we could lock down that OpenAPI schema specifically to only allowstdiofor now.Reacted by Connor PeetI'll get a PR going in the morning
I have a similar concern (not sure it's exactly the same, but given that #148 was closed as a dupe of this, it seems like we're grouping these concerns together).
The current server payload tells me all about the code, including where to get it and how to run it. It tells me as a client what configuration information I need to collect from the user. But in the case of a non-stdio transport, it doesn't tell me how to actually connect to it and use it.
This concern presupposes the case in this issue - that there will exist discoverable, installable MCP servers that present other transports besides stdio (maybe in addition to stdio). So if a server presents streamable, as a client I need to understand that (that I can use the streamable client transport) and I need to know how to configure both the server itself and the client transport (especially the port and path) so that I can connect to it.
As far as I can tell the current assumption is that all non-stdio transport MCP servers will be "remote" (hosted by a third party at a specified endpoint), and I don't think that's the case. I believe that MCP servers, even those intended to be installed locally, will increasingly take advantage of streamable (in part for things like auth), and that there will also be the need to run shared/multi-user streamable servers to serve a local community (and those still have to be discovered and installed).
Reacted by Radoslav DimitrovFrom @evalstate -- A2A's decision to add a transport field could be looked at as a reference: a2aproject/A2A@c3072f5
Another thing to add is that the
Remotepackages inServerDetailalready have the transport type field so it makes sense to have it on thePackagelevel too 👍Done in #345
It was brought up that packages implicitly are stdio servers, but people might want to publish servers that are only streamable HTTP, e.g. to use authentication mechanisms.
If we do this, I would suggest having having an optional
uriTemplateon packages. This is defined as an RFC 6570 template (same format as resource templates in MCP itself) with variables that can reference arguments and environment variables used in that package. This makes it easy to variables likehostandportthat can be reused to form the template.However, a common class of vulnerability is escalation of privilege attacks for services listening on the same device or network, and there is no precedent yet in MCP servers to guard against this (e.g. by having a secret token set in the server's environment variable, required as a header or param on the route, and sent by clients.) So it would be up to servers to guard against this individually, or it would be up to clients to isolate the network of such servers, such as by running them in docker. This makes a safe implementation more complex, in exchange for HTTP-only features (currently just auth.)