Remote MCP calls fail after ~300s with UND_ERR_HEADERS_TIMEOUT, and cancellation does not abort the underlying fetch

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Long-running remote Streamable HTTP MCP tool calls fail after approximately 300 seconds.

Cursor MCP logs show:

TypeError: fetch failed
HeadersTimeoutError: Headers Timeout Error
code: UND_ERR_HEADERS_TIMEOUT

Two reproduced calls failed after 302,099 ms and 302,038 ms.

Cursor bundles Undici 7.25.0, whose default response headers timeout is 300,000 ms. The remote MCP server returns JSON only after the tool finishes, so valid calls longer than five minutes are terminated by Cursor.

Cancellation also does not immediately abort the underlying MCP fetch. The Agent turn was cancelled, but the request continued until the same headers timeout.

Steps to Reproduce

  1. Configure a remote Streamable HTTP MCP server in ~/.cursor/mcp.json.
  2. Invoke a tool that runs for longer than five minutes and does not return response headers before completion.
  3. Wait for the result.
  4. Observe that Cursor fails after approximately 302 seconds with UND_ERR_HEADERS_TIMEOUT.
  5. Start another call and cancel the Agent turn shortly afterward.
  6. Observe that the underlying MCP HTTP request continues until the same timeout.

Expected Behavior

  • Long-running MCP calls should not fail because of an undocumented 300-second response headers timeout.
  • The timeout should be configurable globally or per MCP server/tool.
  • Cancelling an Agent turn should also abort the underlying MCP HTTP request immediately.

Operating System

MacOS

Version Information

Cursor 3.12.30
Commit: 63a2996a10d9e476b6c28e951dd7691d9c0cf480
Architecture: arm64

For AI issues: which model did you use?

GPT-5.6 Sol. This issue is model-independent and occurs in Cursor’s local MCP HTTP transport.

Additional Information

The MCP proxy recorded both requests as client_canceled after 302,018 ms and 302,058 ms. Its configured timeout was 1,800 seconds, while the backend timeout was 10,800 seconds. Neither server-side timeout fired.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

8

Hey there!

1. The ~300s ceiling on remote (Streamable HTTP) MCP calls is real and on us. These calls go through an HTTP client whose default response-headers timeout is 300s, and that limit isn’t something we intend to cap long-running tool calls at. So any server that only sends response headers once the tool finishes gets cut off at ~5 minutes with UND_ERR_HEADERS_TIMEOUT, exactly as you saw. There’s no per-server or global timeout setting exposed today.

2. Cancellation not aborting the underlying request is also confirmed. Cancelling the agent turn currently rejects the call locally but doesn’t abort the in-flight MCP HTTP request or send a notifications/cancelled, so the request keeps running until it hits that same ~300s timeout - which lines up with your proxy logging client_canceled at ~302s.

What unblocks you now (server-side): have your MCP server respond to the tool-call POST immediately with an SSE stream (Content-Type: text/event-stream) and deliver the actual result on that stream once the tool finishes, instead of returning a single JSON body only at the end. Because the response headers arrive right away, the 300s headers timeout never trips and the tool can run well past five minutes. Emitting notifications/progress on that stream while the work runs is good practice too. Servers that block and return a plain JSON body after completion will keep hitting the ceiling no matter how long the work takes.

If reworking the transport isn’t practical, a “start job → poll for status” pattern (where each call returns quickly) is the other reliable way around it.

I’ve reported both the 300s limit and the cancellation behavior to our team, and I’ll follow up here if there’s an update on making the timeout configurable and on cancellation aborting the request. Thanks again - genuinely one of the clearest reports we’ve had.