Claude Code MCP_TOOL_TIMEOUT is about 28 hours; Sume waits 55 s
Claude Code lets a tool call run for about 28 hours by default, but Sume's hosted jobs_wait caps one call at 55 seconds. Why you still loop in short slices.

Claude Code will not cut off a Sume jobs_wait call on its own: its docs say MCP_TOOL_TIMEOUT defaults to about 28 hours when unset. That does not mean you can ask Sume for a long wait. The hosted server clamps every jobs_wait to 55 seconds, so a long render still takes several calls on the same job ids.
The two numbers belong to different layers. One is the client's patience, the other is how long Sume will hold one HTTP request open.
What each side enforces
A wait that stays open sends no data while it runs. Sume's jobs and results page says each edge in front of a server closes such a request at some point, and the caller then gets no tool result while the job keeps running and billing. That is why the server enforces the cap instead of trusting the client's timeout.
| Layer | Setting | Value |
|---|---|---|
| Claude Code | MCP_TOOL_TIMEOUT (per tool call) | About 28 hours when unset |
| Claude Code | Per-server timeout field in .mcp.json | Milliseconds, overrides the env var for that server |
| Claude Code | CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT | 5 minutes default for HTTP servers |
| Sume hosted MCP | jobs_wait timeout_seconds | Default 50, cap 55 |
What to do in a Claude Code session
Treat the long client timeout as headroom, not a plan. Ask for slices of 45 to 55 seconds, pass every in-flight job id in one call (up to 20), and repeat the same call until the jobs are terminal. Sume's docs say a larger timeout_seconds is clamped, not rejected, and the response reports the clamp in wait_slice_clamped.
If a call returns wait_slice_expired or a 524 from the proxy, that is a transport event, not a job outcome. Issue jobs_wait again with the same ids, or read jobs_status once. Never submit the paid create again.
- Do not raise
MCP_TOOL_TIMEOUThoping for a longer hold; it changes only the client side. - Do not report a job as blocked because one wait returned empty.
- Use
include_results: truewhen you want the completed results in the same answer.
The tradeoff
Short slices cost a few extra tool calls and a few extra tokens of conversation. A single 10-minute hold would cost nothing in calls but would die at the edge with a transport error while the job kept billing. Sume chose the first failure mode on purpose.
For a roughly ten-minute render, plan on about a dozen waits at 50 seconds, fewer at 55. The jobs run on Sume the whole time; use jobs_cancel if you want one stopped.
Sources
Related posts
More in Integrations
- Claude Code saves MCP text over 50,000 characters: size Sume reads
Claude Code writes long MCP text results to a file, and Sume caps a tool answer at 256 KiB. Read job waves in batches of 20 ids so each answer stays small.
- Cloudflare Worker: keep the image model id in KV and swap it live
A Worker that proxies POST /v1/images and reads the Sume model id from Workers KV, so replacing gpt-image-1 is a wrangler command, not a deploy.
- Cloudflare Workers cron (UTC) or a Sume schedule with a timezone?
Worker cron triggers run on UTC and take up to 15 minutes to propagate. Sume schedules take an IANA timezone and a skip-or-reject overlap rule.
- Codex startup_timeout_sec 10 and tool_timeout_sec 60 for Sume
Codex defaults to a 10 s startup and a 60 s tool timeout per MCP server. Sume's jobs_wait holds at most 55 s, so the tool default only just fits.
Written by Sume