Claude Desktop mcpToolTimeoutSec 180 s: does Sume jobs_wait fit?

Yes. Claude Desktop v2.110.0 (2026-09-15) added an admin setting named mcpToolTimeoutSec with a default of 180 seconds, and Sume's hosted MCP tool jobs_wait never holds a call longer than 55 seconds, so the default needs no change for Sume.

The setting matters if your organisation lowered it. Anything under about 60 seconds can cut off a jobs_wait slice before it returns, and a cut-off slice is a client-side timeout, not a failed job.

What the setting does

The changelog describes mcpToolTimeoutSec as the time Claude Desktop waits for a single MCP tool call before giving up. It is a per-call ceiling, not a per-job ceiling, which is the right unit for a server that exposes long work as separate create and wait calls.

At a glance

Why 55 seconds is the number that matters

Sume's remote jobs_wait is a bounded slice. The docs ask clients to use slices of 45 to 55 seconds and to re-issue the call on the same job ids. When a slice ends first, the outcome is wait_slice_expired with pending_job_ids, and the job keeps running and keeps being billed.

A timeout in the client therefore looks the same as a normal slice end from the job's point of view. The one rule is to never resubmit the paid create call because a wait looked slow.

• Keep mcpToolTimeoutSec at or above 60 seconds for Sume.
• Pass up to 20 job ids to one jobs_wait call.
• On timed_out or an HTTP 524, call jobs_wait again with the same ids.

Limits and what is not verified

The changelog entry does not say whether a timed-out call is retried by Claude Desktop itself, so the safest assumption is that it is not. Sume's guidance does not depend on it. I did not test the setting against a live Sume session for this post.