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.

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.
| Need | Documented tool |
|---|---|
| Wait a slice | jobs_wait, 50 s default, 55 s cap |
| Wait for many jobs | jobs_wait with job_ids, 1 to 20 ids |
| One-off status | jobs_status |
| Fetch the output | jobs_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
- Claude Code mcp_tool hook on PreToolUse for a spend check
Claude Code 2.1.282 makes mcp_tool hooks on blocking events wait for their MCP server. With Sume, the check to run there is a dry_run cost preview.
- Claude Code "No such tool available" on a resumed MCP session
After resuming a Claude Code session, a first MCP call could fail with No such tool available. Claude Code 2.1.284 waits up to 10 seconds. The Sume side.
- OTEL_LOG_TOOL_CONTENT with MCP tool output: what Sume logs could leak
Claude Code 2.1.283 can put MCP tool output on an OTEL span when OTEL_LOG_TOOL_CONTENT=1. With Sume, check that output for signed URLs and keys first.
- Claude Code PreToolUse hook example: gate paid Sume tools
A PreToolUse hook that lets dry_run previews through, denies paid Sume MCP calls with no max_spend_usd, and asks you before the rest. Script and settings.
Written by Sume