Gemini CLI MCP timeout default vs Sume's 55-second jobs_wait

Gemini CLI's MCP timeout defaults to 600,000 ms, which is ten minutes, while Sume's remote jobs_wait holds at most 55 seconds. The Sume docs give no client timeout to set; repeat jobs_wait on wait_slice_expired instead of waiting longer.

The Gemini default is from the Gemini CLI MCP page; the Sume wait limits from Jobs and results, read 2026-09-30.

Why does the ten-minute default matter?

Sume's docs explain that an HTTP request held for a long time dies at the edge with a 502 or Transport send error before it can answer, and that the old 600-second server-side hold is gone. A wait is meant to be repeated, and the job keeps running and billing between calls.

What values should I compare?

How do I configure the server?

Gemini's page says httpUrl enables the streamable HTTP transport and that timeout sets the request timeout in milliseconds. This entry leaves timeout at its default. Sume's jobs_wait also accepts up to 20 job ids with wait_for set to all or any, so one wait can cover a fan-out.

{
  "mcpServers": {
    "sume": {
      "httpUrl": "https://mcp.sume.com/mcp"
    }
  }
}

What does the agent do when the slice expires?

It calls jobs_wait again with the same ids. It must never resubmit the paid create, because the original job is still running. If a wait uses wait_for: "any", the remaining jobs continue and still bill.

What can the agent pass to jobs_wait?

Sume's docs say timeout_seconds on jobs_wait defaults to 50 and is capped at 55, and that larger values up to 600 are accepted and clamped, with wait_slice_clamped in the response. So the agent does not need to ask for more than the default; it repeats the wait.