Gemini CLI MCP timeout is 600000 ms; Sume jobs_wait caps at 55 s

Gemini CLI's per-server timeout defaults to 600,000 ms, which is 10 minutes. Sume's remote jobs_wait never holds a request longer than 55 seconds, so the client limit is never the one that fires. Set it to about 60,000 ms so a dead connection is reported in a minute, and have the agent repeat jobs_wait for long renders.

What goes wrong with a long client timeout

The Sume docs say that a wait is a single HTTP request that stays open with no data moving, and that edges close such requests. A 524, 522, 523 or 525 on jobs_wait is a transport failure, not a job result. With a 10-minute client timeout, the agent may sit on a dead call far longer than the slice it asked for.

Config

Lower the timeout on the Sume entry only. Other servers keep their own values.

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

The loop to give the agent

Ten-minute renders are normal for some video work. Do not ask for a ten-minute wait; wait again.

• Submit once and keep the job id.
• Call jobs_wait with that id.
• If the answer says wait_slice_expired, call it again with the same id.
• Never re-submit the paid create after a timeout. The job keeps running and billing.
• For several jobs, pass up to 20 in job_ids instead of one call per job.

Why 60 seconds

Sixty thousand milliseconds is five seconds above the Sume cap of 55. It lets a normal slice complete and still reports a hung call quickly. If you use script_run, remember that timeout_seconds goes up to 55 as well, so the same limit covers it.

What a long timeout hides

With the default of ten minutes, a call that the edge dropped does not fail for a long time. The agent sits idle, the job continues to bill, and you may start a second job meanwhile. A short client limit turns the silent hang into a prompt retry of the wait, which is cheap and safe.

If you must run very long scripts, move them off the wait path. Submit the work, store the id, and let a separate scheduled check call jobs_status or a single jobs_wait later. That pattern keeps every individual tool call short and makes each one easy to retry. It also fits the way Sume bills: the job runs and bills whether or not any client is waiting on it, so there is no gain in keeping a connection open.

Before you rely on this setup, run a short acceptance test with a read-only credential. Connect, call mcp_health, call tools_list, and read one job with jobs_status. Record the tool count you see, so you can notice later if a credential change alters it. Then repeat the test after any config edit. A five-minute test like this catches most wiring mistakes before they cost money, and it gives you a baseline to compare against when something behaves differently next week.