Sse Auto Reconnect

[fanslead]

The SSE MCP Server automatically disconnects when there is no interaction for a certain period, and the MCP Client is unaware of this. When the corresponding MCP Server tool is called, an exception occurs.

Expectation: When the tool is called, if the SSE disconnection is detected, the connection should be automatically restored before calling the tool.

[halter73]

The SSE MCP Server automatically disconnects when there is no interaction for a certain period

What SSE MCP Server is this? Do you know what's causing the automatic disconnect? Or do you have diagnostics that show that the server has disconnected and what exactly that means? For example, was there a log or an exception thrown? Or a network trace showing a HTTP/2 STREAM_RST or TCP FIN?

I think this might be a duplicate of #510, but I want to be sure. Do you know that the server does not support Streamable HTTP? I don't recall there being a standard way to reconnect using the legacy HTTP with SSE, so you might be forced to update the server to use the 2025-03-26 or 2025-06-18 Streamable HTTP spec.

[fanslead]

The SSE MCP Server automatically disconnects when there is no interaction for a certain period

What SSE MCP Server is this? Do you know what's causing the automatic disconnect? Or do you have diagnostics that show that the server has disconnected and what exactly that means? For example, was there a log or an exception thrown? Or a network trace showing a HTTP/2 STREAM_RST or TCP FIN?

I think this might be a duplicate of #510, but I want to be sure. Do you know that the server does not support Streamable HTTP? I don't recall there being a standard way to reconnect using the legacy HTTP with SSE, so you might be forced to update the server to use the 2025-03-26 or 2025-06-18 Streamable HTTP spec.

We are using a third-party MCP Server, such as Alibaba Cloud Bailian MCP Server and they not support Streamable HTTP. When the third-party MCP Server's SSE configuration specifies a timeout period for inactivity, after the connection is terminated, subsequent tool invocations by the large language model will fail.

[halter73]

If the third-party MCP Server only supports SSE and is timing out the session, I think you'll be forced to start a new session unless you can prevent the idle timeout in the first place by sending periodic requests or notifications. PingAsync might be a good candidate for the keep-alive loop since that should induce the server to respond over the SSE stream and keep that open.

This makes me think we should expose the completion of McpClient.MessageProcessingTask somehow maybe via a CancellationToken ConnectionClosed { get; } property. This already exposed on the server via RunAsync. In the meantime, you should be able to simply call McpClientFactory.CreateAsync again once you observer an Exception indicating that the client has disconnected. I don't think we'd ever do this completely automatically (at least without an opt-in) since starting a new session can lead to different behavior versus continuing to send JSON-RPC messages over an existing session.

[fanslead]

Yes, while PingAsync is a method to maintain the connection, we still need a publicly available status from McpClient to obtain the latest current status, so that the business side can have a basis to execute the corresponding processing logic.

[PederHP]

I've seen this behavior too, where some servers have very aggressive idle timeouts. I think in general you need to build connectivity resilience into your application, as there are a lot of SDKs out there now, and also some servers built entirely without SDKs. If you use arbitrary 3rd party MCP servers in your app (ie via user-driven config), this isn't optional. The Python and TypeScript SDKs also require you to handle connectivity errors manually and choose your own resilience/reconnection strategy.

[schaveyt]

I think I am facing this issue as well.

I am trying to integrate OpenWebUI's mcpo proxy to communicate with my .NET MCP SSE Server. The initial communication between the mcpo proxy server on my server work great. However, after about 60 secs of idle time the session is dropped on the .NET side...but the mcpo proxy server still continues to make calls

I am other .NET folks are encounter this on that dang mcpo server apparently
open-webui/mcpo#152

I tried the workaround mentioned in that issue noted that sets the idletime to infinite but no bueno 🙃

[jeffhandley]

With the 2026-07-28 specification revision, SSE is deprecated in favor of Streamable HTTP. Because of that, we are closing this as wont fix. If this scenario is still important for down-level SSE support, please open a new issue with the specific compatibility requirement and target environment.