HTTP MCP server becomes unresponsive after repeated SSE stream disconnects

[ericfeh_yahoo (Eric Fehrenbacher)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Summary

An HTTP MCP server (type: http in mcp.json) becomes unresponsive after repeated SSE stream disconnects. The transport logs “will reconnect automatically” but enters a broken state where all requests time out. The server reports 0 tools and appears offline. Toggling the server off/on in Tools & MCP immediately fixes it.

This happens multiple times per session and frequently breaks mid-workflow.

Steps to Reproduce

Steps to reproduce

1. Configure an HTTP MCP server in ~/.cursor/mcp.json with "type": "http" pointing to a remote endpoint
2. Use the server normally — tool calls work fine
3. Wait — the SSE keepalive connection gets terminated by the server roughly every 60 seconds
4. After several SSE disconnects without a tool call in between, the server becomes unresponsive
5. All subsequent tool calls fail with “Tool not found”
6. Toggle the server off/on in Tools & MCP — it works again immediately

What I see in the logs

The MCP log (MCP user-atlassian.log) shows a clear pattern:

Phase 1 — Normal operation with periodic SSE drops:

11:14:42 [info] Found 11 tools, 0 prompts, and 0 resources
11:14:57 [info] SSE stream disconnected, transport will reconnect automatically
         SSE stream disconnected: TypeError: terminated
11:15:23 [info] CreateClient completed, server stored: true
11:15:26 [info] listOfferings: Found 11 tools    ← still working

Phase 2 — SSE drops accumulate when idle (no tool calls to trigger reconnect):

11:31:41 [info] SSE stream disconnected ... TypeError: terminated
11:32:41 [info] SSE stream disconnected ... TypeError: terminated
11:33:42 [info] SSE stream disconnected ... TypeError: terminated
11:34:42 [info] SSE stream disconnected ... TypeError: terminated
11:35:43 [info] SSE stream disconnected ... TypeError: terminated
11:36:43 [info] SSE stream disconnected ... TypeError: terminated
11:37:42 [info] SSE stream disconnected ... TypeError: terminated
11:38:40 [info] SSE stream disconnected ... TypeError: terminated

Phase 3 — Transport is broken, requests time out:

11:45:42 [warning] listOfferingsForUI sub-call failed: MCP error -32001: Request timed out
11:46:42 [warning] listOfferingsForUI sub-call failed: MCP error -32001: Request timed out
11:46:42 [info] Found 0 tools, 0 prompts, and 0 resources    ← server appears offline

Phase 4 — Manual toggle (DeleteClient + CreateClient) fixes it:

11:50:24 [info] Handling DeleteClient action
11:50:24 [info] Cleaning up
11:50:25 [info] Creating streamableHttp transport
11:50:33 [info] Successfully connected to streamableHttp server
11:50:35 [info] listOfferings: Found 11 tools    ← back to normal

This cycle repeats throughout the session. The DeleteClient → CreateClient cycle (triggered by toggling off/on) always fixes it, confirming the transport enters an unrecoverable state.

Expected Behavior

Expected behavior

The StreamableHTTP transport should fully recover from SSE disconnects, or perform an automatic DeleteClient/CreateClient cycle when it detects the transport is in a broken state (e.g., after N consecutive reconnect failures or a request timeout).

Workaround

Manually toggle the MCP server off/on in Tools & MCP. This must be done multiple times per session.

Operating System

MacOS

Version Information

Cursor version: 2.5.17 (arm64)
OS: macOS 15 (Darwin 25.2.0 arm64)

For AI issues: which model did you use?

claude 4.6 opus high

Additional Information

Additional details

• The OAuth token refresh works correctly (expiresIn: 3300, ~55 min cycle) — auth is not the issue
• The SSE disconnect message is always TypeError: terminated, suggesting the remote server closes the SSE connection
• The SSE disconnect interval is roughly 60 seconds, consistent with a server-side keepalive timeout
• The transport claims “will reconnect automatically” but doesn’t fully recover after consecutive disconnects
• Tool calls that happen between SSE disconnects work fine — the issue only manifests when the server is idle through multiple SSE cycles

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report. The step-by-step log breakdown is really helpful.

This looks like a real bug in the StreamableHTTP transport reconnect logic. The pattern you found makes sense. When there are back-to-back SSE disconnects during idle periods, with no tool calls that would trigger a full reconnect, the transport ends up stuck in a state it can’t recover from.

I’ve shared this with the team. Let me know if you notice any changes in newer versions.