Description
Bug description
I'm using this SDK as a remote MCP server with Spring AI
When using WebMvcSseServerTransportProvider
under a Spring MVC (Tomcat) environment,
The request thread hangs indefinitely if the downstream publisher does not emit a value.
This happens because .block()
is called inside the request-handling flow,
causing the Servlet container's worker thread (e.g., http-nio-8080-exec-*
) to block.
If the downstream publisher fails to emit, the thread is never released, leading to thread exhaustion under load.
Environment
- java-sdk: v0.10.0
- Java version: 21
- Server: Tomcat (Spring Web MVC)
- Remote MCP (With Oauth)
Steps to reproduce
- Run Java SDK with WebMvcSseServerTransportProvider
- Within the tool, return a
Mono.never()
or any publisher that never emits - Call the tool via a standard
/mcp/message
call - Observe that the request hangs, and the Tomcat worker thread never completes

As a result, the longer the remote MCP runs, the more worker threads end up hanging.
Additionally, due to this issue, it is currently not possible to scale out the server.
Here's the log I got from the remote MCP server.

Expected behavior
The MCP server should not call .block()
on the request-handling thread.
Either:
- The response should be handled in a non-blocking way using
WebClient
or Project Reactor fully, - or if blocking is absolutely necessary, it should be scheduled on a separate thread via
Schedulers.boundedElastic()
to avoid blocking the Tomcat worker thread.
Minimal Complete Reproducible example