MCP Async Blocking Error

[pram]

Bug description
When calling a streaming chat client with MCP tooling enabled a blocking error is reporting.

2025-02-27T08:13:03.481-05:00 ERROR 1547148 --- [mcp-client] [or-http-epoll-4] o.s.ai.chat.model.MessageAggregator      : Aggregation Error

java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-epoll-4
	at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:87) ~[reactor-core-3.7.3.jar!/:3.7.3]
	at reactor.core.publisher.Mono.block(Mono.java:1779) ~[reactor-core-3.7.3.jar!/:3.7.3]
	at org.springframework.ai.mcp.AsyncMcpToolCallback.call(AsyncMcpToolCallback.java:110) ~[spring-ai-mcp-1.0.0-SNAPSHOT.jar!/:1.0.0-SNAPSHOT]
	at org.springframework.ai.tool.ToolCallback.call(ToolCallback.java:59) ~[spring-ai-core-1.0.0-SNAPSHOT.jar!/:1.0.0-SNAPSHOT]
	at org.springframework.ai.model.tool.DefaultToolCallingManager.executeToolCall(DefaultToolCallingManager.java:226) ~[spring-ai-core-1.0.0-SNAPSHOT.jar!/:1.0.0-SNAPSHOT]

Environment

Java - OpenJDK 64-Bit Server VM Temurin-21.0.4+7 (build 21.0.4+7-LTS, mixed mode, sharing)
Spring AI - 1.0.0-SNAPSHOT
MCP - 0.7.0-SNAPSHOT
Ollama - ollama version is 0.5.12
model - llama3.2:latest
OS - Ubuntu 24.04.2 LTS

Steps to reproduce
Check out the project https://github.com/pram/mcp-async-example

Start the server

cd mcp-async-example
./mvnw clean package
cd mcp-server/target
java -jar mcp-server-0.0.1-SNAPSHOT.jar

Open another window

cd mcp-async-example/mcp-client/target

There are three modes of operation

java -jar mcp-client-0.0.1-SNAPSHOT.jar --app.runner.mode=mcp - Uses MCP Client tooling to call the tool

Output:

Content: TextContent[audience=null, priority=null, type=text, text="Hello Mr Client MCP me old mucker"]

java -jar mcp-client-0.0.1-SNAPSHOT.jar --app.runner.mode=standard - Uses the sync Spring AI chat client

Output:

The function `calculateHello` takes a name as an input and returns a greeting message. Since the input is "James", the output is:

"Hello James, me old mucker!"

java -jar mcp-client-0.0.1-SNAPSHOT.jar --app.runner.mode=stream

Output:

The blocking error as shown above

Expected behavior

I would expect output of the form

Hello
James,
me
old
mucker!

Minimal Complete Reproducible example
https://github.com/pram/mcp-async-example

[pacphi]

I have managed to work around this issue.

Here's what I did in an MCP client impl in cf-kaizen.

I created the following:

• ToolInitializer
• ChatService
• AsyncMcpToolCallback (my own impl riffing off the one in spring-ai-mcp)
• ToolCallbacksReadyEvent

[pacphi]

The two existing classes that caused problems for me because they explicitly call .block():

• AsyncMcpToolCallback
• AsyncMcpToolcallbackProvider

[henningSaulCM]

Ran into this issue ("block()/blockFirst()/blockLast() are blocking") as well when trying to integrate (async) MCP tools into a reactive ChatController (using Spring AI 1.0.0-M6).

Came up with some (ugly) workaround to overwrite/replace AsyncMcpToolCallbackProvider and wrap AsyncMcpToolCallbacks with a custom ToolCallback implementation that uses a ThreadPoolTaskExecutor.

[tzolov]

@pram, @henningSaulCM, @pacphi Thanks for flagging this bug. I've reproduced the issue - the SpringAI API lacks a reactive version of ToolCallback.

I've created a workaround for AsyncMcpToolCallback and AsyncMcpToolcallbackProvider using @pacphi's approach: https://github.com/tzolov/spring-ai/pull/new/fix-2341

The patch fixes https://github.com/pram/mcp-async-example (@pram: remove mcp-bom as spring-ai handles versioning).

@chemicL: Can't we implement a better solution around the Schedulers.boundedElastic()?

[chemicL]

Hey, I opened a PR to address this on the Spring AI level where streaming responses are exercising the synchronous tool calling.

This is a known limitation of the current design, so a thread hop is required to a thread pool that allows blocking.

The workarounds proposed in this PR don't improve things aside from hiding the fact that an event loop is effectively blocked and the scalability is limited. The exception:

java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-epoll-4

is actually quite useful to notice this problem.

A more general refactor of the asynchronous APIs is due in the ChatClient APIs to untangle the synchronous and asynchronous execution paths to be able to avoid unnecessary thread hopping and enable truly async tool calling.