Add transport type property to Packages

[rdimitrov]

Motivation and Context

The following PR:

• Adds the Transport Type property to Packages. Even though most packaged MCP servers are stdio this is not always the case so it's nice to have the option to specify this for clients.
• Adds a constant for the "stdio" type
• Renames the "streamable" one to "streamable-http" (matching better how the spec refers to it)
• Updates the seed.file to reflect these changes

How Has This Been Tested?

Locally

Breaking Changes

No

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

This was discussed in #200

[domdomegg]

lgtm!

for local servers that aren't stdio, can these be easily modelled with the current schema? or what's the general pattern you've seen with these?

[tadasant]

@rdimitrov @domdomegg do we actually want stdio on the Remote object? I don't think that is possible, is it? Remote necessarily implies an HTTP connection.

[tadasant]

I guess if we are having it there for consistency of a unified TransportType, maybe it's fine, no real harm in letting it be there... don't feel strongly, just checking I'm not missing some scenario where this is possible

[rdimitrov]

You're right 👍 I think it's better to leave it out of remotes, I'll file a quick PR to fix that in the schema. Thanks for noticing it.

[rdimitrov]

Fix in - #343

[kkkarthik]

Hello, @rdimitrov
The OpenAPI specification for the official registry API, openapi.yaml have transport_type as streamable and sse
Wouldn't changing streamable to streamable-http raise a value error mentioning that values must be one of ('streamable', 'sse') ?

Or are you planning to change the openapi.yaml specification as well ?

[rdimitrov]

Thank you, @kkkarthik! 🙏 I must have missed it while doing the rename, I'll file a PR shortly 🚀

[rdimitrov]

Fix in - #345

[tadasant]

for local servers that aren't stdio, can these be easily modelled with the current schema? or what's the general pattern you've seen with these?

I think so, should be fine. The pattern is generally something like the usual stdio command plus a flag like --sse. Example of an old one I wrote a while back --

stdio: npx mcp-server-stability-ai -y

SSE: npx mcp-server-stability-ai -y --sse

[rdimitrov]

for local servers that aren't stdio, can these be easily modelled with the current schema? or what's the general pattern you've seen with these?

I think we should have everything necessary to model this 👍

I'm in the process of adopting the ServerJSON format on our side so I'll be able to verify and test this. I'll let you know if I happen to find any issues 👍

[domdomegg]

for local servers that aren't stdio, can these be easily modelled with the current schema? or what's the general pattern you've seen with these?

I guess my concern would be around something like the server runs locally on sse/shttp, but then how do you know what URl to connect at? I guess you could also set remotes? But then if there is a remote and local version, these might be at different endpoints. Or running it with --sse or --shttp suggests different endpoints.

[rdimitrov]

I guess my concern would be around something like the server runs locally on sse/shttp, but then how do you know what URl to connect at? I guess you could also set remotes? But then if there is a remote and local version, these might be at different endpoints. Or running it with --sse or --shttp suggests different endpoints.

I think it's not necessary to be advertised via remotes, usually it's on host-address:8080 (depending on the server there can be a flag/env var to set the port it listens on) and the host-address bit depends on your runtime. From there on if you say you support/want to talk over sse there should be an /sse endpoint and similarly for streamable there's /message I believe (someone correct me if I got it wrong, haven't checked it in detail)