Make MCP scenario tool times out at 25 seconds: Sume job pattern

Make's MCP server gives an AI client your Make scenarios as tools, and it enforces its own tool-call timeouts. Per the Make MCP server page, a scenario run times out at 25 seconds on the OAuth connection and 40 seconds on the token connection, read 2026-10-03. A video or music generation can easily outlast that, so a scenario that calls Sume and waits will look failed to the client while it is still working.

Make states the run does not stop at the timeout: a timed-out scenario keeps running for up to 40 minutes and returns an executionId, which you can look up with the scenarios:read scope. That is the same shape as Sume's own rule. A client timeout is not a job outcome, and it does not cancel anything.

What each side times out on

Sume's limits come from its jobs and results guide and tools and gates page. Every Sume wait window is close to or above Make's shortest limit, so a scenario should never block on generation.

Submit in one scenario, collect in another

Make the first scenario do one thing: call Sume's REST API in async mode and return the job id. Async is the default and answers 202 with status_url, result_url and next_poll_after_seconds. Send an Idempotency-Key on the submit so a retried scenario does not create and bill a second job.

Give the AI client a second scenario, "check job", that takes a job id and calls GET /v1/jobs/:id/status. The status body has terminal, result_ready and sume_status. Only when result_ready is true should it call /result, because that route returns 409 job_not_completed until the job is done.

• Scenario one returns the job id and next_poll_after_seconds inside the 25 seconds.
• Scenario two reads status and returns the result link only when result_ready is true.
• If the client reports a timeout, look up the Make executionId first and the Sume job id second; do not re-run the submit scenario.

Why the retry is the expensive mistake

When an AI client sees a tool timeout it often calls the tool again. For a scenario that only reads data this is harmless. For one that creates a Sume job it is a second charge unless the idempotency key repeats. The Sume docs say a client timeout does not cancel the job and it keeps billing, so make the submit scenario derive its key from the request, not from the run.

If a job is wrong, cancel with POST /v1/jobs/:id/cancel. It returns 409 job_generation_already_started once generation has begun, so cancel early or accept the result.

Choosing the connection type

The OAuth connection has the tighter 25-second window, so if your scenarios are all submit-and-return, either works. The companion post on Make's three connection styles covers where the token lives. Whichever you use, keep the Sume credential inside the Make connection or scenario variables, not in a prompt.