WebClient Streamable HTTP support #292
Conversation
|
The CI fails for the Stdio tests. I can't reproduce it on my M1 Mac, but will try a linux box and investigate. |
|
There is the missing bit for issuing a DELETE upon client-side session termination, I'll investigate how it could be achieved. I will review the spec once more and see what else is missing. |
|
Hi @chemicL thanks for the excellent work! I can run the unit test on our mcp streamable http service. But one issue is that our service is running on springframework 5.3.28. And I notice that your WebClientStreamableHttpTransport only work compatible with springframework 6.2.1. So when I integrate with your code in our service. The below error popped up. this is from spring-web-6.2.1.jar We integrated with HttpClientSseClientTransport before to take care of sse, and the springframework 5.3.28 works fine with the class. Now we would like to upgrade to WebClientStreamableHttpTransport and has this incompatible issue. Is it possible to make it compatible with the old spring version? Thanks! |
|
@bugzyz thank you! We are targetting Spring Framework gen 6, unfortunately. However, in your circumstances, once we introduce the JDK HttpClient support for Streamable HTTP, you should be able to use that in combination with older Spring Framework-based code. That work is coming once we finalize the architectural changes covered here. And then you wouldn't need the mcp-spring module dependency. Hope this helps. |
|
I updated the description in the PR to reflect the architectural overview and decisions to improve the review. @tzolov I'll continue looking into the DELETE aspect and come back either here or via a follow-up PR. |
|
Streamable is finally here:) Thanks! |
|
@bugzyz java8, java11, spring5, etc., can use the solon-ai project https://github.com/opensolon/solon-ai We sync a java8 code and provide a simple experience. |
| this.mcpClientSession.set(mcpClientSession); | ||
| } | ||
|
|
||
| McpClientSession session() { |
There was a problem hiding this comment.
maybe rename to mcpSession() to avoid confusion b/w mcp and transport sessions.
|
|
||
| private Mono<McpSchema.InitializeResult> doInitialize(McpClientSession session) { |
There was a problem hiding this comment.
perhaps rename session -> mcpSession
|
|
||
| } | ||
|
|
||
| private void handleException(Throwable t) { | ||
| logger.warn("Handling exception", t); | ||
| if (t instanceof McpSessionNotFoundException) { |
There was a problem hiding this comment.
If the McpSessionNotFoundException is related to the Transport session a TransportSessionNotFoundException or McpTransportSessionNotFoundException would help to distinct b/w both session abstractions
| /** | ||
| * Get the server capabilities that define the supported features and functionality. | ||
| * @return The server capabilities | ||
| */ | ||
| public McpSchema.ServerCapabilities getServerCapabilities() { | ||
| return this.serverCapabilities; | ||
| Initialization current = this.initialization.get(); |
There was a problem hiding this comment.
This is repeating and can be abstracted:
Initialization current = this.initialization.get();
McpSchema.InitializeResult initializeResult = current != null ? current.result.get() : null;
| if (previous != null) { | ||
| previous.close(); | ||
| } | ||
| withSession("re-initializing", result -> Mono.empty()).subscribe(); |
There was a problem hiding this comment.
Not sure what the result -> Mono.empty() means?
|
|
||
| private AtomicBoolean initialized = new AtomicBoolean(false); | ||
| private final AtomicReference<Initialization> initialization = new AtomicReference<>(); |
There was a problem hiding this comment.
maybe we should be more explicit in naming like initializationRef ?
Introducing WebClient support for Streamable HTTP transport.
Motivation and Context
The 2025-03-26 specification of MCP introduces Streamable HTTP transport that replaces SSE transport.
This change introduces more resilient primitives that support the initial, WebClient-based client transport for Streamable HTTP.
Various failure modes at either the transport or logical layer have been addressed and are now fully supported by the new
WebClientStreamableHttpTransportclass. The surroundingMcpAsyncClientandMcpClientSessionhave been modified to handle possible issues according to the adequate layer's responsibility.Orientation
The existing APIs are organized quite logically with regards to various responsibilities using layers. Below is the status quo description and the changes required for Streamable HTTP to be implemented.
Rationale for the API
The client types are layered in the following way:
Here are the distinguishing features of these APIs:
McpAsyncClient(and the facade,McpSyncClient)Mcp(Client)SessionMcp(Client)TransportMcpTransportSessionMcpTransportStreamHow Has This Been Tested?
everythingMCP server.Breaking Changes
The client initialization became lazy and more error-prone - connections happen upon first request and initialization is performed implicitly if it has not been issued before.
Types of changes
Checklist
Additional context
The JDK HttpClient will be implemented next.
Remaining tasks
Related #72