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.

[Randgalt]

Virtual threads are here. As we move into the future v-threads will be the norm. This library should segregate the reactive portions so that they can be ignored in the future. My 0.02.

[edeandrea]

There's this long conversation as well about it

https://github.com/orgs/modelcontextprotocol/discussions/246

[Randgalt]

FWIW we’ve moved on and are no longer using this library.

[edeandrea]

I happened to stumble upon this thread today and have been advocating for some time (1 year?) that a general purpose library like this should not be tightly-coupled with libraries such as project reactor.

The thread I posted has the history of that as well as many others who were advocating for this as well.

[sdeleuze]

Reactor being a mandatory dependency of this project has never been a goal per se, just a consequence of multiple things:

• Java 17 baseline with Virtual Threads not mature enough
• Reactive Streams (whatever flavor you use) is just 4 interfaces for the SPI that requires a Reactive Streams implementation that comply with the huge Reactive Streams TCK
• Need for streaming and async/scalable execution

Sure Virtual Threads is there for some time, but exposing I/O related streaming in an idiomatic way in such architecture, the fact that it requires a Java 21 (in practice more a Java 24/25 due to pinning threads) baseline and the fact that Structured Concurrency is still in preview and various open questions made it not possible to use it as a foundation.

That said, as shared in #778 this is about to change, and we are planning to introduce a unified and first-class Virtual Threads friendly API that will IMO solve most of the concern that have been raised. That will take multiple steps to move to an ideal state but I am pretty excited about this new direction and hope we will be able to collaborate on that with the MCP community.