Support for "Streamable HTTP" Transport

[richieto]

Is your feature request related to a problem? Please describe.

As a developer using the Typescript SDK for the Model Context Protocol (MCP), I need it to support the new "Streamable HTTP" transport introduced in PR modelcontextprotocol/modelcontextprotocol#206 of the specification repository. Without this update, the SDK will be incompatible with servers adopting the new transport, causing integration issues and preventing me from leveraging the specification’s latest improvements.

Describe the solution you'd like

I’d like the Typescript SDK to be updated to implement the "Streamable HTTP" transport as outlined in PR
This includes:

• Removing the /sse endpoint.
• Routing all client-to-server messages through the /message endpoint.
• Supporting server-upgraded SSE for notifications and requests.
• Implementing session IDs for state management.
• Enabling clients to initiate SSE streams with an empty GET to /message.
• The implementation should also address any backwards compatibility requirements specified in the PR.

Describe alternatives you've considered

One alternative is manually patching the SDK to support the new transport, but this isn’t a sustainable solution. Another option is waiting for the maintainers to address this independently, but filing this issue ensures the change is tracked and prioritized proactively.

Additional context

The details of the "Streamable HTTP" transport are in PR of the MCP specification repository: modelcontextprotocol/modelcontextprotocol#206. Updating the SDK is essential to keep it aligned with the latest MCP standard and to ensure seamless integration with updated servers.

[richieto]

be aware of modelcontextprotocol/modelcontextprotocol#205

[mralbertchen]

Is this as simple as creating a new Transport named StreamableHttpTransport and adding some tests? Or are there other considerations?

[QuantGeekDev]

I added support for this to mcp-framework, I assumed this was being worked on already but I'm happy to add this to the sdk. Would that be helpful?

[cliffhall]

I added support for this to mcp-framework, I assumed this was being worked on already but I'm happy to add this to the sdk. Would that be helpful?

@QuantGeekDev there is a promising PR for it already. Any review comments you could add there would be great, since you've been through the process.

[ddebrunner]

@cliffhall the promising PR #230 is just server-side right, additional work would be needed to support clients?

[cliffhall]

@cliffhall the promising PR #230 is just server-side right, additional work would be needed to support clients?

@ddebrunner Yes, that PR just adds the StreamableHTTPServerTransport and unit tests for it. The Inspector would need to be upgraded to support it and the servers project would need at least one good example. Not sure if there is more work to be done in the SDK to support client use of this transport. A transport is a transport, so I think probably not. If there are glaringly missing bits, please mention them here.

@jspahrsummers Have you had a look at that PR? Can you weigh in on any missing pieces?

[ddebrunner]

@cliffhall I'm new to this code, but I tried StreamableHTTPServerTransport as a client and it failed, and then I saw that (and assumed) there are server and client variants of transports, as for example there's server/sse.ts and client/sse.ts.

SSEClientTransport and SSEServerTransport are different types.

[cliffhall]

Yep, you are right. You need both, but I'm not sure that they have to both come in the same PR if the server transport is unit tested and seems viable, another PR could be opened for the client transport.

[gylove1994]

Hi, @ddebrunner I'd like to add an Client Transport after StreamableHTTPServerTransport is working well.

[gylove1994]

Should I merge the Client Transport into #230, or would it be better to open a new PR for this? 🤔 @cliffhall

[stevensu1977]

Hi , @gylove1994 , I think if merge Client Transport into #230 together , it's better than open a new PR.

Should I merge the Client Transport into #230, or would it be better to open a new PR for this? 🤔 @cliffhall

[cliffhall]

Should I merge the Client Transport into #230, or would it be better to open a new PR for this? 🤔 @cliffhall

A new PR is better. It's two developers, so if further changes are required, its messy, who will fix them. They'll both end up in the same release, but they can be decoupled for the purposes of contribution.

[gylove1994]

Should I merge the Client Transport into #230, or would it be better to open a new PR for this? 🤔 @cliffhall

A new PR is better. It's two developers, so if further changes are required, its messy, who will fix them. They'll both end up in the same release, but they can be decoupled for the purposes of contribution.

My point is that if no one is available to take over the "Client Transport" development, I'd be happy to complete it. However, ​if I were to open a new PR for this, it might complicate integration testing prior to merging, compared to maintaining it within the current workflow. ​If you think a new PR is better, I'll fully respect your decision.

[cliffhall]

Should I merge the Client Transport into #230, or would it be better to open a new PR for this? 🤔 @cliffhall

A new PR is better. It's two developers, so if further changes are required, its messy, who will fix them. They'll both end up in the same release, but they can be decoupled for the purposes of contribution.

My point is that if no one is available to take over the "Client Transport" development, I'd be happy to complete it. However, ​if I were to open a new PR for this, it might complicate integration testing prior to merging, compared to maintaining it within the current workflow. ​If you think a new PR is better, I'll fully respect your decision.

That's a fair take. Are you planning to add the integration tests in the same PR?