Repository navigation
Support "Streamable HTTP" transport #72
Description
Activity
- changed the title
[-]When is the "Streamable HTTP" transport scheduled to be supported?[/-][+]Support "Streamable HTTP" transport[/+]on Apr 7, 2025 When is 2025-03-26 Implementation 's release date? thx @chemicL
stare
I would love to contribute on this feature.
I started diving into the subject and began prototyping it. If there arise some areas where contributions will be useful, I will update this issue with links to individual tasks. Thanks for your patience.
Reacted by hongling, Thomas Schaffter, rokaye, Kent Pun, Naveen Ramachandrappa, Corby Page, JANG WOOJIN, krzysztof-osiecki, Maximilian Schellhorn, Jordi Böhme and 9 moreReacted by He-Pin(kerr), Hakenadu, WuTao and Dorian MüllerFolks, feel free to test locally the work in progress in #292 and please report any issues. We will follow up with the JDK HttpClient implementation and then take care of the server side.
Reacted by jielihaofeng, WuTao, codezjx, Aliaksei and Yuriy PylypenkoReacted by Hakenadu- marked [Question] Which version is targeting the delivery of the changes in the 2025-03-26 specification #216 as a duplicate of this issue
on Jun 4, 2025 - marked Is there any plan to support streamable HTTP? #186 as a duplicate of this issue
on Jun 4, 2025 Hey, @ZachGerman. I must admit I haven't been actively reviewing nor following the issues/PRs recently. I see you did some work there which looks promising and thank you for the effort. If you'd like, please consider an integration test including the WIP client introduced here. In the future, please keep in mind our contributing guidelines before implementing a major feature.
We really need this feature. When will it be available? @chemicL
Reacted by realreus319, Yuriy Pylypenko and Yu3 remaining items
Not sure if I should limit my efforts to finishing server, or if I should finish that entire WIP draft PR as well. Please advise.
Please focus on finishing the server - it would be most beneficial and hopefully minimize unnecessary implementation overlaps.
Reacted by Zachary German, Mukul Singh and Olaf DsouzaThanks for the recent updates and all the great work!
I noticed that a PR has been opened to implement Streamable HTTP transport, which seems to overlaps with my earlier PRs. To help reduce noise and duplication, I’ll go ahead and close my PRs.
However If it’s helpful, feel free to reuse any code or ideas from my PRs( PR1, PR2 ) — happy if any part of them is useful moving forward. :-)
(a bit beyond this issue sorry)
I’d love to know if there’s any interest in the SPI refactoring proposal I made earlier (PR), if not that's totally fine — just let me know so I can decide whether to maintain it in a separate fork instead — just let me know what you prefer ;-)Thanks again and looking forward to where the SDK goes next!
— @Aliaksie- added a commit that references this issue
on Jun 10, 2025 We merged the JDK-based Streamable HTTP client in #337.
@Aliaksie thank you for the effort you put into this. As a strategic part of the SDK, we needed to invest the time to digest the spec and implement the client which required quite a few changes not considered in the proposed PRs.
For the SPI work, it is not the right moment for it. When we stabilize the feature set there should be the place for it, but we have to do it in the least disruptive manner. For substantial work, please work with us inside an issue to avoid doing unnecessary work, as we've tried to explain in the contributing guidelines.
Thanks for being a kind and supportive community member!
Reacted by Christian Tzolov, Wang Feng and Thomas Schaffter- added 6 commits that reference this issue
on Jul 26, 2025 resolved !
Reacted by finyuq and WuTaoReacted by Dariusz Jędrzejczyk, monnetchr, Cathy, finyuq, Michael Grondines and fkirchhoff- added a commit that references this issue
on Jun 25, 2026
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone
(Original content)
Expected Behavior
The "Streamable HTTP" transport is a fantastic feature, particularly beneficial for stateless MCP servers and remote MCP servers in distributed scenarios. It enables MCP to be swiftly employed in production-grade agent applications
Current Behavior
The issue with the current session is that it needs to support distributed sessions.
(Edit by @chemicL follows)
To split the task, what needs to happen to consider it done:
Steps