[BUG] Remote MCP connector silently stops sending requests and reports the server offline; server logs show zero requests received

What's Wrong?

A remote MCP connector (Streamable HTTP + OAuth) intermittently enters a state where the client stops issuing requests entirely while reporting the server as unavailable ("tools won't load", "the MCP server is offline").

Server-side logging proves that during these periods no requests are made at all. Not failed requests, not rejected ones, not even a TCP connection that breaks. The application log and the reverse proxy in front of it both record nothing.

Recovery requires toggling the connector's permission setting in the UI, which appears to force re-initialisation. Notably:

• Waiting does not recover it.
• Removing and re-adding the connector does not recover it.
• Only the permission toggle does, and lately it has needed several attempts plus a session refresh.

While in this state, the client's tool search reports "Found tools" but no tools/list reaches the server, which suggests it is reading a locally cached registry that has been emptied.

I run the server, so I have both sides of this. Happy to provide more detail or test a fix.

What Should Happen?

The client should retry the connector, or at minimum surface that it has stopped attempting requests rather than attributing the failure to the server. Reporting a server as offline without having contacted it sends users (and their agents) chasing a non-existent server-side fault.

Error Messages/Logs

Server side, from the most recent occurrence. Times are UTC; the user was at UTC+5:30.

09:35:00 – 09:45:21   NOTHING RECEIVED (application log and reverse proxy both silent)

  09:40      user attempts a query, client reports the server offline
  09:41:53   client: "offline again right now (tools won't load)"
  09:43:55   user toggles connector permission, client: "back"

09:45:21  request tenant=… method=tools/call tool=run_gaql outcome=ok ms=1398
09:45:24  request tenant=… method=tools/call tool=run_gaql outcome=ok ms=1031
09:45:25  request tenant=… method=tools/call tool=run_gaql outcome=ok ms=764
09:45:26  request tenant=… method=tools/call tool=run_gaql outcome=ok ms=690

Four successful calls in five seconds, none slower than 1.4 s, immediately after the toggle. The server returned no 4xx, no 5xx and no timeout at any point in the surrounding period, and was serving other users normally.

An earlier occurrence, same pattern: the client declared the server offline and armed an auto-retry loop, then roughly seven minutes later the same workspace successfully created four ads. The client's own summary of that run stated that nothing had been applied, which was wrong.

Steps to Reproduce

I do not have a deterministic repro, which is the main thing I am missing. What I can say about conditions, across three captured occurrences:

1. Connect a remote MCP server over Streamable HTTP with OAuth as a custom connector.
2. Work with it over a long session, including resuming sessions.
3. Intermittently the connector enters the state above.

Strongest correlation: Resumed session appears in the transcript immediately before all three observed failures. That is the detail I would investigate first.

Possibly relevant, possibly not:

• Client is geographically distant from the server (India to Germany, ~1 s round trip for a trivial request). A slow but stable path may interact with a health-check timeout.
• The failure has followed bursts of parallel tool calls, and at least once followed a tool call the client itself cancelled.

Additional context

Server configuration, in case it narrows things:

• FastMCP over Streamable HTTP, stateless_http=True, json_response=True
• OAuth 2.1 authorization server with Dynamic Client Registration
• mcp 1.28.1, fastmcp 3.4.2, protocol version 2025-06-18

Two things ruled out during the investigation, to save anyone repeating them:

1. Not credentials. The OAuth grant chain rotated cleanly four times across the affected period, with no replayed, expired or rejected token. No authentication failure was logged at any point.
2. Not the missing server-initiated stream. Because the server is stateless it answers GET /mcp with 405, which I suspected might trip a client-side health check. But this client never issues a GET at all, so that is not the trigger here.