The heart beat (ping) is not working in streamable-http

[und3rs]

Bug description
The streamable-http server closes the connection immediately after responding to the client’s request.
As a result, the server fails to send ping messages to the client.
Since IDEs like Cursor do not receive the ping, they mark the MCP server as closed (red state) after the idle-timeout period.

Environment
Spring AI: 1.1.0
Webflux

Steps to reproduce
You can test this issue with below example.

1. Use this source code
   https://github.com/spring-projects/spring-ai-examples/tree/main/model-context-protocol/weather/starter-webflux-server

2. Change protocol from STATELESS to STREAMABLE in 'application.properties'
   spring.ai.mcp.server.protocol=STREAMABLE

3. Add following settings into 'application.properties'
   logging.level.root=DEBUG
   spring.ai.mcp.server.keep-alive-interval=30s
   spring.ai.mcp.server.streamable-http.keep-alive-interval=30s

4. Start webflux-mcp-server and wait after connection with mcp client.

• Request "Initialize" and "tools/list"

5. Monitor logs
   2025-11-13T10:47:56.059+09:00 DEBUG 22168 --- [ctor-http-nio-3] io.modelcontextprotocol.spec.McpSchema : Received JSON message: {
   "jsonrpc": "2.0",
   "id": "list-1",
   "method": "tools/list",
   "params": {}
   }
   2025-11-13T10:47:56.088+09:00 DEBUG 22168 --- [ctor-http-nio-3] o.s.w.s.adapter.HttpWebHandlerAdapter : [f1db6cad-2] Completed 200 OK
   2025-11-13T10:47:56.088+09:00 DEBUG 22168 --- [ctor-http-nio-3] r.n.http.server.HttpServerOperations : [f1db6cad-2, L:/[0:0:0:0:0:0:0:1]:8080 - R:/[0:0:0:0:0:0:0:1]:55851] Last HTTP response frame
   2025-11-13T10:47:56.088+09:00 DEBUG 22168 --- [ctor-http-nio-3] r.n.http.server.HttpServerOperations : [f1db6cad-2, L:/[0:0:0:0:0:0:0:1]:8080 - R:/[0:0:0:0:0:0:0:1]:55851] Decreasing pending responses count: 0
   2025-11-13T10:47:56.089+09:00 DEBUG 22168 --- [ctor-http-nio-3] r.n.http.server.HttpServerOperations : [f1db6cad-2, L:/[0:0:0:0:0:0:0:1]:8080 - R:/[0:0:0:0:0:0:0:1]:55851] Last HTTP packet was sent, terminating the channel
   2025-11-13T10:47:56.089+09:00 DEBUG 22168 --- [ctor-http-nio-3] r.netty.channel.ChannelOperations : [f1db6cad-2, L:/[0:0:0:0:0:0:0:1]:8080 - R:/[0:0:0:0:0:0:0:1]:55851] [HttpServer] Channel inbound receiver cancelled (subscription disposed).
   2025-11-13T10:48:20.038+09:00 WARN 22168 --- [oundedElastic-1] i.m.util.KeepAliveScheduler : Failed to send keep-alive ping to session io.modelcontextprotocol.spec.McpStreamableServerSession@5fd8c0ef: Stream unavailable for session f7223451-6867-4b8c-8b46-e8ded21a7691

Expected behavior
The webflux-mcp-server should keep the connection open after sending a response to the client’s request.
It must only close the connection according to the logic defined in the KeepAliveScheduler.

Minimal Complete Reproducible example
https://github.com/spring-projects/spring-ai-examples/tree/main/model-context-protocol/weather/starter-webflux-server

[JGoP-L]

hi @ilayaperumalg @tzolov

I believe the issue is not in Spring AI, but rather in the MCP Java SDK.

Problem Location:

• Project: MCP Java SDK (io.modelcontextprotocol.sdk:mcp-spring-webflux)
• File: WebFluxStreamableServerTransportProvider.java
• Issue: After the Initialize request returns a single JSON response, the HTTP connection closes immediately, preventing KeepAliveScheduler from sending keep-alive ping messages.

Fix Approach:

Change the Initialize request response from a single JSON response to an SSE streaming response to keep the connection open, allowing KeepAliveScheduler to send keep-alive ping messages.

Key Fix Points:

1. Change response format: from APPLICATION_JSON to TEXT_EVENT_STREAM (SSE)
2. Wrap the JSON-RPC response in the data field of an SSE event
3. Create a listeningStream for keep-alive ping
4. Keep the connection open through SSE streaming response

Compatibility:

Fully backward compatible - clients already support SSE, users don't need to modify any code or configuration.

If you agree, I can submit a PR in the MCP Java SDK.

[tzolov]

@und3rs, I can not reproduce your issue.
I've tested with both Inspector and Cursor and can confirm that the keep alieve messages are sent on the configured intervals.
To send ping message from a streamable server you need to use the provided exchange.

[und3rs]

You most likely tested this in a localhost environment.
Let me clarify a few points to help your understanding:

In WebFlux (Netty), the default idle timeout is unlimited.
This means the issue cannot be reproduced unless an idle timeout is explicitly configured.

Firewalls or load balancers typically have a default idle timeout of around 60 seconds.
The issue can be reproduced in such environments.

To prevent connections from being closed due to idle timeouts, ping/pong messages are used.

The MCP client (such as Cursor IDE) also uses this mechanism.