MCP standardized error handling: Sume's named outcomes

Standardized error handling across MCP surfaces is a roadmap topic, not a finished spec, so a client has to handle each server's named outcomes itself. Sume's hosted MCP gives four you will meet: insufficient_scope, wait_slice_expired, a 524-class transport failure, and operator_stopped. Each one maps to a different action.

The roadmap page (last updated 2026-08-22) lists "standardized error handling across all surfaces" under HTTP-native transport work and says the roadmap reflects current thinking rather than firm commitments. Sume facts below are from Jobs and results and MCP OAuth and API keys, read 2026-10-01.

Which Sume outcomes should my MCP client expect?

Four, and they are not interchangeable. Two are about what the session may do, two are about waiting on a job. Treating them all as "tool failed" is how a client ends up resubmitting a paid create.

What should I do on insufficient_scope?

Stop calling the tool and change the credential. The docs say mcp:read sessions only see read-only tools and that missing write on a mutating tool returns insufficient_scope. Granting write is a consent choice on the MCP host (Write is off by default), and an API key is the other path. Legacy allow_write and allow_paid flags cannot bypass a missing mcp:write scope, so retrying with them changes nothing.

What should I do on wait_slice_expired?

Retry. The docs say every remote HTTP POST /mcp caller holds at most 55s per call, and that on wait_slice_expired you retry jobs_wait with the same ids, never resubmit the paid create. Wait for a ten-minute render by repeating the wait, not by asking for a longer one; larger values are clamped and the response says so in wait_slice_clamped.

// Re-issue the same wait; never re-send the create.
let result;
do {
  result = await callTool("jobs_wait", { job_ids: ids, timeout_seconds: 50 });
} while (result.outcome === "wait_slice_expired");

Is a 524 on jobs_wait a failed job?

No. The docs call a 524 (or 522 / 523 / 525) on jobs_wait a transport failure, never a job outcome. The job keeps running and billing. Re-issue the wait on the same ids, or read jobs_status once, and do not report the job as blocked.

When is a job really stopped?

outcome: "operator_stopped" is the terminal case: Sume operations stopped at least one id, the jobs produce no output, and their holds were refunded. operator_stopped.pending_job_ids names ids still running, and re-issuing the wait on the stopped ids cannot change the answer. For the full code list see MCP error codes.