Trae MCP timeout: RUN_MCP_TIMEOUT_MS in headers vs Sume jobs_wait

In Trae, the HTTP MCP timeout lives in the headers object: Trae's docs show START_MCP_TIMEOUT_MS and RUN_MCP_TIMEOUT_MS, both at 60000 in the example, for the server's startup and for invoking its tools. Sume's hosted jobs_wait holds one call open for at most 55 seconds, so keep RUN_MCP_TIMEOUT_MS above 55000 or pass a shorter timeout_seconds to jobs_wait.

Sources, read 2026-10-06: Trae's Add MCP servers page and Sume's Jobs and results.

What does the Trae example look like?

Trae's page says stdio servers take these two keys in env, and HTTP servers take them in headers. The example value is "60000" for both, each commented as a timeout in milliseconds. The page does not state a default for the keys, so set them explicitly. Because they sit in headers, treat them as Trae-specific settings in the entry for Sume alongside Authorization.

"headers": {
  "Authorization": "Bearer YOUR_SUME_API_KEY",
  "START_MCP_TIMEOUT_MS": "60000",
  "RUN_MCP_TIMEOUT_MS": "60000"
}

Why 55 seconds matters

Sume's docs say remote MCP jobs_wait defaults to 50 seconds when timeout_seconds is omitted and caps at 55, and that a wait is one HTTP request held open for the whole slice. A client limit shorter than the slice ends the call with no tool result while the job keeps running and keeps billing.

So for a ten-minute video render, do not ask for a longer wait. Call jobs_wait again with the same ids when it answers wait_slice_expired. A client-side timeout or an edge error such as a 524 is a transport failure, never a job outcome, and Sume's docs say not to submit the paid create again or report the job as blocked.

Safe recovery after a Trae timeout

These steps come from the Jobs and results page; none depends on Trae.

• Keep the job id from the create response; it is durable.
• Call jobs_status once, or jobs_wait again with the same ids.
• If you must retry the create itself, reuse the same idempotency_key so the retry returns the original job.
• With several jobs in flight, jobs_wait takes job_ids (1 to 20) and wait_for of all or any; with any, the other jobs keep running and billing.