Haystack MCPTool 30-second timeout vs Sume jobs_wait holds

Haystack's MCPTool defaults to 30 seconds for connection_timeout and 30 seconds for invocation_timeout, per its integration reference. Sume's jobs_wait holds one call open for 50 seconds when you omit timeout_seconds and for at most 55. With defaults on both sides, a wait on an unfinished job outlasts Haystack's invocation limit.

Pick one fix: set invocation_timeout above 55 (60 is a safe value), or call jobs_wait with timeout_seconds of 25 or less and loop. Both facts were read on 2026-10-06; Sume's side is on Jobs and results.

Which fix is better?

Raising the limit is simpler. Shortening the wait suits a pipeline that has its own time budget per step.

What happens when the wait ends early?

A timeout on the client side does not cancel the job. It keeps running and keeps billing, per Sume's docs. Keep the job id, call jobs_wait again with the same ids when the answer is wait_slice_expired, and never submit the paid create again. If you must retry a create, reuse its idempotency_key.

One wait for a whole fan-out

After parallel creates, jobs_wait takes job_ids (1 to 20) with wait_for of all (default) or any, and include_results: true returns each completed job's result in the same answer. That is one tool call, so one Haystack invocation timeout, for a whole wave.