Sends a heartbeat (ping) to all connected clients to keep connection…

[FrolikovEA]

…s alive. This method sends ping notifications to all active sessions without expecting a response, which helps prevent connection timeouts.

@return A Mono that completes when heartbeat has been sent to all sessions

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[FrolikovEA]

Sends a heartbeat (ping) to all connected clients to keep connections alive. This method sends ping notifications to all active sessions without expecting a response, which helps prevent connection timeouts.
@return A Mono that completes when heartbeat has been sent to all sessions

[tzolov]

@FrolikovEA can you elaborate on this? What connection timeouts do you see.
Also we just added the server ping() support, e.g. you can send pings but only from within the context of a running server operation (e.g. tool call, resource read, ....): #347

[FrolikovEA]

Good afternoon @tzolov
this is a standard problem when using nargs in cursor
this method will help to periodically ping all sessions so that the connection does not drop.
for example, this is how I call it in Spring

@Bean
public Disposable heartbeatLoop(WebFluxSseServerTransportProvider provider) {
    return Flux.interval(Duration.ofSeconds(40))
            .flatMap(t -> provider.sendHeartbeat())
            .subscribe();
}

[chemicL]

I am wondering if it wasn't easier if we exposed McpAsyncServer#ping() and McpSyncServer#ping() which would go over all the currently connected clients and send ping to them. That would take care of the global SSE connection with the legacy SSE transport and in Streamable HTTP it would also address the global GET SSE stream.

Why in the Mcp*Server instead of transport? Because it's a domain level method meant for heartbeat and the domain level methods are there and also in McpAsyncServerExchange and McpSyncServerExchange - these would allow you to send periodic pings in case of a slower response with the Streamable HTTP transport.

[tzolov]

McpAsyncServer#ping() and McpSyncServer#ping() methods for broadcasting pings to all connected clients would be useful, following patterns from other SDKs.

TODO: PING is a request, not a notification. The current McpServerTransportProvider#notifyClients only supports notification broadcasting. We'd need something like McpServerTransportProvider#requestClients or McpServerTransportProvider#pingClients.

Temporary solution: @FrolikovEA could you try using the existing McpAsyncServer#loggingNotification and McpSyncServer#loggingNotification methods that already broadcast to all connected clients?

Still PING's advantage might be its silent acknowledgment with empty responses, providing bidirectional communication validation.

Alternative: In system-design to setup a heart-beat, one would use HTTP keep-alive configuration with an HTTP proxy server for production MCP deployments - likely the standard cloud setup anyway.