MCP error -32001: Request timed out, -32000: Connection closed, and other errors your client makes up

2026-10-27MCP Checkup

"MCP error -32001: Request timed out" and "MCP error -32000: Connection closed" are not answers from the MCP server. Your client's SDK makes them up when a request gets no answer: the server took longer than the timeout (60 seconds by default), or the connection to it ended while the request was waiting. Fix the cause on the connection or the server, or raise the timeout.

The protocol's own codes, which a server sends back in a JSON-RPC error, are a separate list: see MCP error codes explained. This page covers only the errors the client creates itself. The SDK details were checked on 2026-10-28 against the TypeScript SDK source, v1.x and main.

The client-side errors at a glance

You see (TypeScript SDK v1)	Code	When	In v2 (`main`)
`MCP error -32001: Request timed out`	`RequestTimeout`	No answer within the timeout, 60 seconds by default	`SdkError`, code `REQUEST_TIMEOUT`, message `Request timed out`
`MCP error -32001: Maximum total timeout exceeded`	`RequestTimeout`	Progress kept the request alive, but `maxTotalTimeout` ran out	`SdkError`, code `REQUEST_TIMEOUT`
`MCP error -32000: Connection closed`	`ConnectionClosed`	The connection ended while requests were waiting	`SdkError`, code `CONNECTION_CLOSED`, message `Connection closed`

In v1 every one of these is an McpError, and its message is always MCP error <code>: <message>. The two numbers come from the SDK's own ErrorCode list. They sit in the range JSON-RPC leaves to implementations, so another SDK, or a server, can use -32000 for something else.

MCP error -32001: Request timed out

The client sends a request and starts a timer. If no response arrives before it runs out, the SDK cancels the request and fails it with -32001. The default is 60,000 ms (DEFAULT_REQUEST_TIMEOUT_MSEC).

The timeout is per request, so a slow tool can get a longer one without changing the rest. In v1, callTool takes the request options as its third argument:

const result = await client.callTool(
  { name: "build_report", arguments: { month: "2026-10" } },
  undefined,
  {
    timeout: 120_000,              // wait up to 2 minutes for this call
    onprogress: (p) => console.log(p),
    resetTimeoutOnProgress: true,  // each progress notification restarts the timer
    maxTotalTimeout: 600_000,      // but never wait more than 10 minutes in total
  },
);

resetTimeoutOnProgress only has an effect with an onprogress handler, because the SDK asks the server for progress notifications only when you pass one. If the total time passes maxTotalTimeout, the error is Maximum total timeout exceeded, still code -32001.

Before raising the number, check where the time goes:

The tool is slow. Make it report progress, or return quickly with a job ID the model can check on later.
The server never answers. A handler that throws without sending a response, or a request the server dropped, looks exactly like a slow tool from the client. Look at the server log for that request.
Something in between holds the response. A proxy that buffers streamed responses until they end can hold a long response back past the timeout.

MCP error -32000: Connection closed

When the transport closes, the SDK fails every request still waiting with MCP error -32000: Connection closed. Over stdio that usually means the server process exited: it crashed on start, could not find a dependency, or wrote something other than JSON-RPC to stdout. Over HTTP, the stream or the session ended. MCP error -32000: Connection closed goes through the causes one by one.

MCP error -32000: Request was cancelled uses the same code for a different case, and the connection itself is fine. It comes from inside a request handler: the other side cancelled the request it was handling, and the handler then tried to send a request of its own, such as a sampling or elicitation request back to the client.

What changes in v2 of the TypeScript SDK

On the main branch (v2), errors the client creates itself are SdkError values, not McpError. Their codes are strings, SdkErrorCode.RequestTimeout ('REQUEST_TIMEOUT') and SdkErrorCode.ConnectionClosed ('CONNECTION_CLOSED'), and the message has no MCP error <code>: prefix. It is just Request timed out or Connection closed.

Code that matches the numbers stops matching after the upgrade:

// v1
if (err instanceof McpError && err.code === ErrorCode.RequestTimeout) { /* -32001 */ }

// v2
if (err instanceof SdkError && err.code === SdkErrorCode.RequestTimeout) { /* 'REQUEST_TIMEOUT' */ }

The same goes for log searches and alerts that look for the text -32001 or -32000.

Client error or server error?

What you have	Who made it
An exception with no HTTP response or JSON-RPC message behind it	Your client's SDK: this page
A JSON-RPC `error` object in the response body	The server or its SDK transport: MCP error codes explained
HTTP 406 with `Not Acceptable: Client must accept both application/json and text/event-stream`	The server's transport: the 406 guide
A `result` with `isError: true`	The tool ran and failed: read its text

FAQ

Does "MCP error -32001: Request timed out" mean the server is down?

Not necessarily. It means no response arrived within the client's timeout, 60 seconds by default. The server may be up but slow, or it may have dropped that one request. A server that is down usually fails sooner, with a connection error.

How do I change the MCP request timeout?

Pass timeout in the request options: in v1 of the TypeScript SDK, the third argument of callTool. Add onprogress with resetTimeoutOnProgress: true for long tools that report progress, and maxTotalTimeout as an upper bound.

Why does the error say -32000 when the server never sent an error?

Because the client made it up. -32000 is the TypeScript SDK's own ConnectionClosed code, used when the connection ends while requests are waiting. The SDK also uses it for "Request was cancelled", inside a handler whose request the other side cancelled.

Check what the server does from outside

When the client says a request timed out and you are not sure the server answered at all, paste the server's address at mcpcheckup.com. It connects the way an agent does, lists the tools, and shows where the connection stopped and why.