AgentSDK (and ChatGPT UI) fails running time-consuming MCP tool with "TypeError: fetch failed"

API
,
1

I’ve been trying to get both AgentSDK and the ChatGPT UI to connect to my own StreamableHTTP MCP server and run a long-running tool (let’s call this MandatoryTool) that takes more than five minutes.

Behavior in Agent SDK

I found that the timeout field in MCPServerStreamableHttp successfully extends the timeout—as long as the value is under five (?) minutes.

If MandatoryTool takes about 10 minutes and I set the timeout to something like 1 minute, I get the following timeout error, which makes sense.

{“name”:“tool_output”,“item”:{“type”:“tool_call_output_item”,“rawItem”:{“type”:“function_call_result”,“name”:“MandatoryTool”,“callId”:“call_jM2RMukc1zPcwpPWKu4i03Ss”,“status”:“completed”,“output”:{“type”:“text”,“text”:“An error occurred while running the tool. Please try again. Error: McpError: MCP error -32001: Request timed out”}},“agent”:{“name”:“GitMCP Assistant”},“output”:“An error occurred while running the tool. Please try again. Error: McpError: MCP error -32001: Request timed out”},“type”:“run_item_stream_event”}

However, if I set the timeout field to something longer (say 20 minutes), I still get the error below, which seems to occur five minutes after the MCP tool call.

{“name”:“tool_output”,“item”:{“type”:“tool_call_output_item”,“rawItem”:{“type”:“function_call_result”,“name”:“MandatoryTool”,“callId”:“call_wPTzf6UJeechStNpaKqHI4Sj”,“status”:“completed”,“output”:{“type”:“text”,“text”:“An error occurred while running the tool. Please try again. Error: TypeError: fetch failed”}},“agent”:{“name”:“GitMCP Assistant”},“output”:“An error occurred while running the tool. Please try again. Error: TypeError: fetch failed”},“type”:“run_item_stream_event”}

Behavior in ChatGPT UI

In the UI, I get the below error (according to the LLM) after 5 minutes.
( I assume this is not configurable? )

ConnectorClientServerError: 500: “Server returned 500: ‘Request timeout’”

Question

Is this five-minute error a known limitation, or is it a bug?

In some applications, it makes sense to design MCP tools in a more batch-like fashion—for example, generating a task ID and letting the backend monitor progress. But in chat-based interfaces (such as the ChatGPT UI), that pattern doesn’t work well, because it forces the user to repeatedly ask the LLM something like “Is your work done yet?”

I understand that OpenAI generally discourages long-running blocking operations, but this behavior places significant limits on the usability of MCP tools for cases where longer operations are unavoidable.

(Or maybe I’m simply doing something wrong!)

1 Like
2

What are you working on? What’s the use case?Saw a similar problem myself and solved it with durable execution infrastructure.

1 Like
3

Hi Bonexit, thank you for your reply!

An example would be something like audio transcription tool, or video generation tool (this may not take more than 5 minutes with latest models depending on the length of the video).
I also tried to connect to another AI that has a bunch of tools (or maybe MCP is not the right way).

4

This is pretty close to the use case I was tackling. Although with research tooling instead of video generation. I’d be happy to talk through your setup on a call if you’d like. I’m trying to figure out if I can just opensource what I already have so it’ll be helpful both ways. There is a calendar link in my profile if you want to chat. Otherwise, happy to talk through it here too.

5

I feel like there’s quite a big time difference between us, so lets stick with this thread for now.

One of my MCP tool literally requires a single OpenAI Response API call, but still takes more than 5 minutes with gpt-5, gpt-5.1 (even with reasoning effort set to none). Besides changing the model to something smaller (e.g. gpt-5-nano), is there a way to speed this up or allow MCP client not to timeout or end with error? Gpt-5-nano can return within 3 mintues but obviously lowers the quality.

Btw, Chat GPT UI custom MCP connector used to be down yesterday, fixed today but seems like MCP tool call timeouts in 1 min now (last week I think it was 5 min but who knows…).