Claude Code MCP progress notifications on a background call: Sume

Claude Code 2.1.283 fixed MCP progress notifications dropped on background calls. Sume's docs describe bounded jobs_wait slices instead of a progress stream.

4 min readSume
All posts

Claude Code 2.1.283 fixed MCP progress notifications that were discarded once a tool call moved to the background. Sume's docs do not describe a progress stream for its tools. They describe something plainer: jobs_wait returns within 55 seconds, and you repeat it until the job is terminal.

What did the fix change?

The changelog for 2.1.283, dated Sep 25, says it fixed MCP progress notifications being discarded for background tool calls. That helps servers that emit progress. It says nothing about servers that do not.

Does Sume emit progress for a long render?

The docs read for this post do not mention progress notifications, so do not build on them. What they document is a bounded wait: on remote MCP, timeout_seconds defaults to 50 and is capped at 55, values up to 600 are accepted and clamped, and the response says so in wait_slice_clamped.

What to rely on for a long Sume job, read 2026-09-29.
NeedDocumented tool
Wait a slicejobs_wait, 50 s default, 55 s cap
Wait for many jobsjobs_wait with job_ids, 1 to 20 ids
One-off statusjobs_status
Fetch the outputjobs_result

How do I wait for a ten-minute render?

Repeat the wait, not a longer one. Sume's docs say a wait returns the moment its job is terminal, and that on wait_slice_expired you retry jobs_wait with the same ids and never resubmit the paid create.

What if a wait fails at the edge?

A 524, 522, 523 or 525 on jobs_wait is a transport failure, never a job outcome. Re-issue jobs_wait on the same ids, or read jobs_status once. The job keeps running and keeps billing in the meantime, so do not report it blocked.

For many parallel jobs, prefer one batch wait with wait_for set to all or any; it reports every id either way.

Does the background move change what I do?

Not for the job. Sume's docs say the job runs and keeps billing whether or not the caller is waiting, so a caller that goes to the background does not stop it. Track the job id, not the call.

Claude Code 2.1.284 also lists that MCP tool calls in a resumed session wait up to 10 seconds for the server. After a resume, re-read jobs_status for any job id you hold rather than assuming the earlier wait finished.

What about a stateless server?

The same 2.1.283 entry lists a fix for a stateless remote MCP 404. Sume's docs give you nothing to configure here, since the client connects to the hosted URL. If a call fails, read jobs_status rather than assuming the job failed.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume