MCP error -32000 connection closed: what Sume's -32000 means
MCP error -32000 is implementation-defined. Sume returns it only when its MCP work budget is full; a client's own connection closed text is a different thing.

A client message that says "connection closed" with code -32000 is usually the client reporting that its transport ended, not a Sume reply. When Sume itself returns -32000, the message is "MCP work budget is full; retry shortly." and it means the server is shedding load, not that your request was malformed.
The code range is from the MCP 2026-07-28 changelog; Sume's behavior is from the MCP server source and docs, read 2026-10-01. I could not tell from these sources which client produces the connection-closed text, so check yours.
What range is -32000 in?
The changelog defines an error code allocation policy: -32000 to -32019 remains implementation-defined, with existing SDK usage grandfathered, and -32020 to -32099 is reserved for the MCP specification. So -32000 means whatever the sender says it means; read the message text.
When does Sume return it?
Only for non-tools/call requests while admission is rejecting work. A paid tools/call under the same pressure gets a tool error instead, with this rule: retry only the rejected call with the same idempotency_key after retry_after_seconds. Other codes are separate.
| Situation | What you get |
|---|---|
| Work budget full, non-tool request | JSON-RPC -32000, "MCP work budget is full; retry shortly." |
Work budget full, tools/call | Tool error with code wait_busy, HTTP status 429 in the error data |
| Unsupported protocol version | -32600, "Unsupported MCP protocol version." |
| Unknown method | -32601 |
What should I do when I see it?
Stop fanning out new submissions and drain what you have. The docs say to prefer one batch wait after parallel fan-outs instead of N single waits: see MCP jobs_wait for long video jobs. Then retry only the rejected call, with the same key, never a fresh key, so a paid create cannot run twice.
Is it a connection problem?
If you got a JSON-RPC body with the budget message, the connection worked. If you got no body at all, look at your transport and proxy timeouts first; the docs note an HTTP request held too long dies at the edge before it can answer, and that jobs_wait slices are at most 55 seconds. A closed connection says nothing about whether a paid job was created, so read job state before resubmitting.
Sources
Related posts
More in Developers
- MCP ETag on tool results: Sume idempotency_key and job reads
ETag-versioned MCP tool results are a roadmap idea. In Sume, idempotency_key is write dedup, not a cache validator; job reads are separate read tools.
- MCP GET stream endpoint removed: Sume GET /mcp returns 405
MCP 2026-07-28 removes the GET stream endpoint. Sume's remote MCP already answers GET /mcp with 405 and Allow: POST, so send every message as an HTTP POST.
- MCP human-presence attestation: Sume consent vs API key
Human-presence attestation is only a roadmap topic. Sume separates people from automation by credential: OAuth consent in a browser, or an API key.
- MCP Inspector custom headers: send one Sume API key
In MCP Inspector's custom headers, send either x-api-key or Authorization: Bearer with your Sume key, never both. Sume rejects a request carrying both.
Written by Sume