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.

4 min readSume
All posts

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.

Sume remote MCP server source, read 2026-10-01.
SituationWhat you get
Work budget full, non-tool requestJSON-RPC -32000, "MCP work budget is full; retry shortly."
Work budget full, tools/callTool 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

All Developers posts

Written by Sume