# HTTP MCP server becomes unresponsive after repeated SSE stream disconnects **URL:** \ **Category:** Bug Reports\ **Tags:** mcp\ **Created:** [February 19, 2026, 3:06am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243 "2026-02-19T03:06:56Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![ericfeh\_yahoo](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/ericfeh_yahoo/32/98757_2.png) [@ericfeh\_yahoo](https://forum.cursor.com/u/ericfeh_yahoo)\ **Post date:** [February 19, 2026, 3:06am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243/1 "2026-02-19T03:06:56Z")
### 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:** ```auto 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):** ```auto 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:** ```auto 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:** ```auto 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 ---
**Author:** ![deanrie](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/deanrie/32/1263_2.png) [@deanrie](https://forum.cursor.com/u/deanrie)\ **Post date:** [February 19, 2026, 11:14am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243/3 "2026-02-19T11:14:41Z")
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. ---
**Author:** ![system](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/system/32/99069_2.png) [@system](https://forum.cursor.com/u/system)\ **Post date:** [March 13, 2026, 11:15am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243/6 "2026-03-13T11:15:20Z")
Closed on March 13, 2026, 11:15am UTC This topic was automatically closed 22 days after the last reply. New replies are no longer allowed. ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [April 21, 2026, 8:35am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243/8 "2026-04-21T08:35:58Z")
Opened on April 21, 2026, 8:35am UTC ---
**Author:** ![mohitjain](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/mohitjain/32/100229_2.png) [@mohitjain](https://forum.cursor.com/u/mohitjain)\ **Post date:** [April 21, 2026, 8:36am UTC](https://forum.cursor.com/t/http-mcp-server-becomes-unresponsive-after-repeated-sse-stream-disconnects/152243/9 "2026-04-21T08:36:14Z")
Hey @ericfeh_yahoo, The issue with HTTP MCP servers becoming unresponsive after repeated SSE stream disconnects has been addressed and the fix should be available on the nightly release channel. If you’d like to try it out before it hits stable: open **Cursor Settings \> About** and switch the **Release Track** to **Nightly** , then restart Cursor. Let me know if that resolves it!