We are using agentbuilder to build workflow. As shown in the following figure, we have added our own remote MCP server (Streamable HTTP) in the agent. But during runtime, we received many 424 errors without any detailed information to explain what exactly caused them.
But the correct result can be obtained by calling it through methods such as curl or fastmcp client.
After multiple debugging attempts, we found that this may be due to the tool running for too long, causing the agent to actively disconnect and report error 424.
We found that if the tool’s runtime is controlled to return results within one minute, the agent can process them normally. But if the tool runs for more than 120 seconds (or even less), it will report error 424.
We are now wondering if there is any way to handle this long-running tool, or if there is any place to adjust the default timeout?
Same for me, i checked twice and request failed with 424 error after 1 minute.
From my tool I send a progress event — it looks like the API can rely on such events and reset the timeout to the beginning, since the connection is active and nothing is stuck on the server side, or alternatively rely on ping events.
Can you elaborate on it?
I tried the following solutions but none of them worked:
- Change the tool to an iterator for streaming return
- Change the startup mode of MCP server to SSE
- Tool sends progress events, example code:
from fastmcp import FastMCP, Context
import asyncio
mcp = FastMCP("ProgressDemo", port=8003)
@mcp.tool
async def scan_directory(directory: str, ctx: Context) -> dict:
"""Scan directory with indeterminate progress."""
files_found = 0
for i in range(120):
files_found += 1
# Report progress without total for indeterminate operations
await ctx.report_progress(progress=files_found)
await asyncio.sleep(1)
return {"files_found": files_found, "directory": directory}
if __name__ == '__main__':
mcp.run(transport="streamable-http")
Stuck with same error. On my server I send progress notifications, but openai’s client is ignoring them and not restarting the timeout.
Hello!
Our eng team deployed a fix for MCP 424/timeouts in early December to resolve the main timeout error. If you’re still seeing 424s, it would be great if you could share timestamps, logs, and whether your MCP uses SSE or streamable HTTP so we can escalate.
Thank you!
Hi, this is great news, but a bit vague! Can you please elaborate on how the fix is working? Has the 60 seconds timeout been removed? Or is still there, but can be reset from server side in some way? Or even better have you added support for MCP progress (i.e. are you finally adding a proper progress token)?
Thanks!
Great question. Caveat that I could be mistaken, but from what I can see, the December fix makes the model and platform fail more gracefully at timeout (removing the previous noisy/special-token failure), but it did not remove the platform timeout (the ~60s–1–2 minute window remains enforced at various layers). Progress events from your MCP do not currently reset that timeout and there is no universal “progress token” yet, but we're working to improve this behavior going forward.
Thanks, I confirm that. Sadly, it did not solve my problem. The 60 seconds timeout is still there, and progress tokens are missing. Please give this appropriate urgency (long running agentic jobs depends on this) and keep us posted.
Any update on this?
I’m also facing timeouts after exactly one minute