Claude Code MCP tool idle timeout versus a silent Sume jobs_wait

The default idle window for HTTP servers is already five minutes, so Sume works out of the box; if you lowered CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT, keep it at 60000 or more (or 0 to turn the check off). A Sume jobs_wait can sit open for up to 55 seconds without sending anything back, and an idle window shorter than that could abort the call even though the job is healthy.

Claude Code's MCP docs (read 2026-10-02) describe the variable as the idle window, in milliseconds, before a tool call that sends no response and no progress notification aborts; 0 disables the check, and the default is five minutes for HTTP servers. The Sume numbers come from Jobs and results.

Idle timeout or total timeout: which one is this?

Claude Code has two different limits, and mixing them up causes confusing aborts. MCP_TOOL_TIMEOUT and a per-server timeout in .mcp.json bound the whole call. The idle timeout bounds how long a call may go without activity. A per-server timeout field in .mcp.json overrides MCP_TOOL_TIMEOUT for that server, and the idle variable is separate from both.

The page gives the default idle window for HTTP servers as five minutes, so a fresh install already clears Sume's 55-second hold. If your calls abort around a number you did not set, something has lowered the variable.

Why is a Sume wait silent?

Sume's docs describe a jobs_wait as one HTTP request held open for the whole slice with nothing transferring. The cap is 55 seconds on remote MCP, with a default of 50. Sume deliberately does not allow longer holds: an HTTP request held for ten minutes would die at the edge before it could answer, which the docs mention as a 502 or Transport send error.

That makes a quiet 50 to 55 seconds normal. It is not a sign the job is stuck. The docs add that an image still running at 50 seconds is usually stuck rather than slow, which is a job-level judgment, not a transport one.

What if the call aborts mid-wait?

The abort ends Claude's attempt, not the job. The generation keeps running and keeps billing. Re-issue jobs_wait on the same ids, or read jobs_status once. Never resubmit the paid create, and never report a job blocked because a wait aborted; the docs treat transport errors (524, 522, 523, 525) the same way, as failures of the request and not outcomes of the job.

If you must submit again for another reason, reuse the original idempotency_key for the exact same payload. A new key means a new job.

How do I set it?

Use the environment variable for the session, or put it in your shell profile if every Claude Code session talks to Sume.

Then ask Claude to call jobs_wait on a running job and confirm it returns a wait_slice_expired or terminal state rather than aborting. For per-server total limits, see Claude Code MCP tool timeout.

export CLAUDE_CODE_MCP_TOOL_IDLE_TIMEOUT=120000
claude mcp list

Do I need this at all for Sume?

Possibly not. If you never changed the idle variable and your Sume waits already complete, leave it alone. The setting matters in two cases: a managed or shared shell profile that sets a short idle window for other, chattier servers, and a CI image that tightened every timeout. In both, the symptom is the same. A jobs_wait call fails on the Claude side at roughly the same moment each time, while jobs_status or jobs_list on the same job shows it still running.

A quick way to tell the two limits apart is to run a short jobs_wait with timeout_seconds of 10. If that returns and a 50-second wait aborts, you have an idle or total limit between those two values. Compare it with the per-server timeout in .mcp.json and the MCP_TOOL_TIMEOUT value; whichever is smaller than 55 seconds is the culprit. You can also lower the Sume slice instead of raising the client limit: a timeout_seconds of 25 keeps each call comfortably quiet-safe, at the cost of more repeats. Because every repeat is a read, it does not spend anything.