MCP error -32001: Request timed out: How to Fix It (Claude Desktop, Claude Code, Cursor)

MCP error -32001: Request timed out means the client sent a request to your MCP server and gave up waiting for a reply. In the official TypeScript SDK, the default wait is 60 seconds. The fastest fix depends on when it happens: at startup, make the server answer faster (no slow downloads or logins before it reads stdin); during a tool call, raise the client's tool timeout or make the tool report progress.

Checked against: the source of the @modelcontextprotocol/sdk 1.32.2 npm package, the MCP 2026-07-28 cancellation and timeouts page, the Claude Code MCP docs and Claude's connector authentication docs on 2 November 2026. eSEOspace did not reproduce timeouts in each client.

What this error means

Every MCP request has an ID, and the client waits for a response with the same ID. The 2026-07-28 spec says that when no response arrives "within the timeout period, the sender SHOULD cancel the request and stop waiting." On stdio, cancelling means sending a notifications/cancelled message.

The spec also says implementations "MAY choose to reset the timeout clock when receiving a progress notification," but "SHOULD always enforce a maximum timeout." The 1.32.2 SDK follows this with two options: resetTimeoutOnProgress and maxTotalTimeout.

Note that -32001 is a local error. The spec says errors "purely local to an implementation (for example, a request timeout raised inside an SDK) are not currently assigned codes." The SDK chose -32001, and the 2026-07-28 spec places -32000 to -32019 in a legacy range with no fixed meaning.

A public bug report shows the pattern. In a Desktop Commander issue, the server log shows the client's initialize request at 19:42:22, then a cancellation with "MCP error -32001: Request timed out" at 19:43:22. That is exactly 60 seconds.

Quick fix

1. Find out which request timed out. Read the client log. If it is the first request (initialize or server/discover), the server is slow to start or never answered. If it is tools/call, the tool is slow.
2. For slow startup: run the server once by hand so npx or uvx caches the package. Pin a version, and move logins or index builds to after the server starts reading stdin.
3. Check for blocking output. A server that waits on a prompt, such as an interactive login, never answers.
4. For slow tools: raise the client's tool timeout (below), or make the tool start a background job and return quickly.
5. Send progress notifications from long tools so clients that reset on progress keep waiting.
6. Restart the client and retry.

Fix by client / OS

Claude Code

The Claude Code MCP docs give three settings:

• Startup: MCP_TIMEOUT=10000 claude sets a 10-second server startup timeout. Raise the number for slow servers.
• All tool calls: set MCP_TOOL_TIMEOUT in milliseconds. The docs say the default is "about 28 hours when that variable is unset."
• One server: add "timeout": 600000 to that server's .mcp.json entry for ten minutes. It overrides MCP_TOOL_TIMEOUT for that server only.

{
  "mcpServers": {
    "reports": {
      "command": "/usr/local/bin/reports-mcp",
      "timeout": 600000
    }
  }
}

The setup guide claude mcp add command shows where .mcp.json lives.

Claude Desktop

We found no timeout setting for local servers in Claude Desktop's documentation as of November 2026. Fix the cause instead: warm the package cache, remove slow startup work, and read mcp.log and mcp-server-SERVERNAME.log in ~/Library/Logs/Claude (macOS) or %APPDATA%\Claude\logs (Windows), per the MCP debugging guide.

Remote connectors in Claude

Claude's authentication docs say Claude waits up to 10 seconds for OAuth discovery, registration and token endpoints, and up to 30 seconds for refresh requests. A slow token endpoint "produces intermittent connection failures." If you run the server, keep these endpoints fast and check that a proxy is not buffering the response.

Cursor and VS Code

Neither Cursor's MCP docs nor VS Code's MCP pages list a per-tool timeout setting as of November 2026. Use their logs (Cursor MCP Logs; VS Code MCP: List Servers > Show Output) to see which request stalled, then fix it on the server side.

Your own client code

If you write a client with the TypeScript SDK, pass a timeout in the request options. Combine resetTimeoutOnProgress: true with a maxTotalTimeout so a server that keeps sending progress cannot hang forever, as the spec advises.

Where to find the logs

• Claude Desktop: mcp.log plus the per-server log.
• Claude Code: /mcp and claude mcp get <name>.
• Cursor: Output panel, MCP Logs.
• Server side: log timestamps at request start and end to stderr. Our logging and monitoring lesson explains what to record.

If it still fails

• Timeouts plus a closed connection may mean the server crashed. See MCP error -32000: Connection closed.
• Only large results time out. Paginate or summarize the result. The spec's pagination pattern helps.
• Long jobs by design. Look at the Tasks extension in MCP Apps, Tasks and Skills for work that should run in the background.
• Check the code. Paste any other code into the MCP error code lookup.

Need a server that handles long jobs without timeouts? Our MCP development team builds them.

Frequently asked questions