Sume MCP read_busy 503: four concurrent reads per owner

read_busy is a retryable 503 from Sume's MCP host. Reads inside tools, including jobs_wait polls, are capped at 4 at once per owner, 512 across the host.

5 min readSume
All posts

read_busy means Sume's MCP host is already running its limit of hosted reads, and the message is "MCP reads are busy; retry shortly." The error is retryable, carries HTTP status 503, and is not a failed job. The limit applies to GET reads that happen inside tools, including the polls that jobs_wait makes. Each owner may have 4 in flight at once, and the host holds 512 in total.

The budgets side by side

The per-owner figure is keyed by workspace and owner, so two terminals using the same key share it. Studio agent turns use a separate per-turn cap, which is not what an outside client sees.

MCP admission budgets in the Sume repo (as of 2026-10-09); per-owner applies to API key and OAuth callers
BudgetTotalPer ownerBusy error
Hosted reads inside tools5124read_busy, 503
jobs_wait holds1,0248wait_busy, 429
Tool calls1,0244wait_busy, 429 after queuing
Create calls1,02420wait_busy, 429 after queuing

What to do on read_busy

Retry only the call that failed, after a short wait, and do not fan out more reads in response. Reads are safe to repeat. A write or paid call that was rejected before it ran can be retried with the same idempotency_key, so nothing is billed twice.

The more useful fix is to send fewer reads. One jobs_wait covers up to 20 job ids, so a loop that polls 20 jobs one by one uses up to 20 times the read budget of a single wait. Keep one jobs_wait for all pending ids and re-issue it in 45 to 55 second slices instead of polling each id.

  • Use jobs_wait with several job_ids rather than one status call per job.
  • Back off for a second or more before retrying a read_busy.
  • Do not open a second jobs_wait for the same ids; it spends the wait budget too.

Telling the busy errors apart

read_busy is 503 and about reads. wait_busy is 429 and about waits and tool calls. Both are transient, and neither means a job failed or that your credential is wrong. A 401 or insufficient_scope is a different category and retrying will not help.

A retry helper

A small wrapper keeps this contained: catch read_busy, wait one to two seconds with a little jitter, and try the same read again up to three times before surfacing the error to the user. Do not wrap write or paid calls in the same loop unless they carry a stable idempotency_key, because a fresh key on every attempt turns a retry into a second job.

Sources

Related posts

More in Integrations

All Integrations posts

Written by Sume