feat(client): adds StreamableHttpClientTransport

[Aliaksie]

adds StreamableHttpClientTransport

Motivation and Context

it is enabler for support 2025-03-26 version of protocol

How Has This Been Tested?

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

The server implementation and the 2025-03-26 scheme will be added as separate PRs.

[chickenlj]

Great job @Aliaksie

Here are some of my thoughts after reading this PR and the SDK source code.

I think just adding the McpClientTransport implementation cannot give full support for Streamable HTTP because how it works is inconsistent with HTTP+SSE in many places, which might require some redesign or refactoring of the current SDK implementation:

1. The initialization process is not necessary in Streamable HTTP, it is only required when implementing stateful management. After initialization, all subsequent requests are required to have a mcp-session-id header. However, the current Java SDK implementation enforces checking of initialization status and does not manage the mcp-session-id after initialization.
2. /mcp GET requests are constrained in the protocol to be used when the client wants to initiate a SSE request proactively, while the current implementation initiates a GET request and establishe SSE session every time on transport connect. Subsequent POST requests also rely on this to send back responses, which can be seen through the operation of the pendingResponses field.

[Aliaksie]

Great job @Aliaksie

Here are some of my thoughts after reading this PR and the SDK source code.

I think just adding the McpClientTransport implementation cannot give full support for Streamable HTTP because how it works is inconsistent with HTTP+SSE in many places, which might require some redesign or refactoring of the current SDK implementation:

1. The initialization process is not necessary in Streamable HTTP, it is only required when implementing stateful management. After initialization, all subsequent requests are required to have a mcp-session-id header. However, the current Java SDK implementation enforces checking of initialization status and does not manage the mcp-session-id after initialization.
2. /mcp GET requests are constrained in the protocol to be used when the client wants to initiate a SSE request proactively, while the current implementation initiates a GET request and establishe SSE session every time on transport connect. Subsequent POST requests also rely on this to send back responses, which can be seen through the operation of the pendingResponses field.

Hey @chickenlj Thanks a lot for the thoughtful feedback!

1 I added to Streamable HTTP transport code to manage mcp-session-id, and I checked documentation (transports and lifecycle ) and it seems to me that initialization request is still required, even in Streamable HTTP but the server may or may not return a mcp-session-id
2 Yes — that’s a really important. I added the logic to make connect lazy and optional with default connect on init for for backward compatibility...

I hope all this makes the SDK compliant with Streamable HTTP's flexibility while still maintaining support for HTTP+SSE fallback

[Aliaksie]

Hey @tzolov, hope you're doing well! Just wanted to check in — have you had a chance to review this PR? I’d appreciate any feedback when you get a moment. Looking forward to your thoughts!

[shaohzhangebay]

Hi team, could you please share the timeline to have streamable http for mcp java sdk ?

[skyrdis]

when this feature could be ready to be parity with typescript and python?

[Aliaksie]

Hi @tzolov👋 Just checking in to see if there’s been a chance to review this PR

Would love to hear if this makes sense for the SDK or if I should revise or break it down further.
Thanks a lot for your time!