How to describe a package that supports multiple transports?

[vanyauhalin]

Right now, the author of an MCP server has to specify exactly one transport that the MCP server supports. But what if the MCP server supports multiple transports?

For example, I developed an MCP server and published it to the npm registry. Users can now use the npx command to run the MCP server. Through environment variables, users can choose the transport type: streamable-http or stdio.

MCP_TRANSPORT=stdio npx my-mcp-server

MCP_TRANSPORT=stremable-http npx my-mcp-server

Following: https://github.com/modelcontextprotocol/registry/issues/143

[rdimitrov]

Hey, @vanyauhalin, thanks for reaching out 🙏

I'm linking a reply to a similar discussion - https://github.com/modelcontextprotocol/registry/discussions/404 but the tldr is I think it's a valid point and we should implement it 👍

[vanyauhalin]

Hi, @rdimitrov. Thank you for such a fast response. Would it be a solution for now to duplicate the package description with different transport types?

[vanyauhalin]

One side note. An MCP server could potentially work with multiple transports at the same time, ex. sse+stremable-http. Maybe the schema should reflect this.

[rdimitrov]

One side note. An MCP server could potentially work with multiple transports at the same time, ex. sse+stremable-http. Maybe the schema should reflect this.

I agree 👍 I think making the transportType property a list should be explicit enough to hint that the same package (MCP server) offers multiple transports, right?

Would it be a solution for now to duplicate the package description with different transport types?

That sounds reasonable 👍

[leefowlercu]

As an example the io.github.bytedance/mcp-server-browser Server Version 1.0.0 currently has 3 Package definitions, each of the same Registry Type and Identifier but with different Transports defined.

@rdimitrov

I agree 👍 I think making the transportType property a list should be explicit enough to hint that the same package (MCP server) offers multiple transports, right?

Servers may have different interfaces (e.g. package arguments) defined when different Transports are used. For instance it's probably common to have a required--port argument to the Server when the Transport is streamable-http or sse whereas that argument would probably not be expected when running in stdio mode. It's therefore probably best to tie Transport Types 1:1 with Package definitions, since Package Arguments are associated with a singular Package definition on the Server Version.

[tadasant]

I think @leefowlercu is spot-on with the original intent when we were designing this:

Servers may have different interfaces (e.g. package arguments) defined when different Transports are used. For instance it's probably common to have a required--port argument to the Server when the Transport is streamable-http or sse whereas that argument would probably not be expected when running in stdio mode. It therefore probably best to tie Transport Types 1:1 with Package definitions, since Package Arguments are associated with a singular Package definition on the Server Version.

But you all are right that it's odd (and not DRY) to duplicate an entire Package entry just to tweak the Transport.

It may be worth adjusting the shape so that there is some key inside Package, maybe something like PackageInstallation, that contains fields like runtime_hint, transport, etc within it, but not file_sha256, version, etc? And that field could be 1..*? What do you all think is the right solution here?