Why is Project Reactor so pervasive in all the project?

[juliojgd]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Sorry if this was already explained but I haven't found anything that explains it (e.g. here).

I was expecting to find Project Reactor in Webflux related modules or even in non-webflux but asynchronous components. But I was surprised to find it here in the McpSyncServer class. That class seems to be a mere "adapter" when you want to use non-reactive components, but under the hood it calls to the McpAsyncServer (reactive) class by calling .block() in each reactive operation.

I understand this was done this way in order to centralize all behavior in one of the "flavors" and to adapt the other one without the need of a generalized abstraction.

I'm aware that the current implementation will work as well with Java 21+ and that implementing a pure non reactive option for McpSyncServer will be a potential architectural change but I'm curious about the reasons to include Project Reactor so core-inside the SDK. And if to have a non reactive implementation for "blocking" servers was ever considered.

Thanks in advance for any answer.

P.D. I found #192 but the discussion was not answered nor explained.

[luyiourwong]

MCP is designed for AI interaction — meaning heavy I/O concurrency and the need for backpressure handling. It basically stops just short of naming Project Reactor directly. Honestly, I doubt a blocking thread server could even run in production under realistic load. McpSyncServer feels more like a checkbox — “yes, we have a blocking version.”

BTW, I do agree that a base SDK should aim to be as dependency-light and close to native Java as possible. But to realistically support the needs of MCP, you at least need virtual threads from Java 21 to get anything close to viable performance in a blocking style. Every other workaround hits clear performance bottlenecks.