MCP error -32001: Request timed out

MCP error -32001: Request timed out

MCP error -32001: Request timed out

Which clients print it: Obsidian connector #300 (opens in a new tab) reports Claude Desktop through mcp-remote timing out on remote HTTP initialization in June 2026. Qwen #7147 (opens in a new tab) records it while listing tools, prompts and resources after authentication. These are examples of the older SDK wording; do not assume every current SDK uses this numeric code.

Likely causes, ranked by recurrence in the reports

1. A request never receives its matching reply. Both remote reports describe successful setup stages before a stalled operation. Identify the last completed method, request id and whether a response reached the client before the deadline.
2. The client deadline is shorter than real work. REA #1720 (opens in a new tab) diagnoses a client-owned deadline independent of a configured backend startup limit. Compare handler completion time with cancellation time.
3. Streaming or gateway delivery stalls. If the handler completed promptly but the reply did not arrive, inspect buffering, response ids and stream closure. This is a diagnostic hypothesis; the error alone cannot prove a slow handler.

The ranking is a qualitative reading of the linked cases, not measured incident frequency.

Fix for client users

Distinguish connection setup from a per-request deadline. Record the failing method and elapsed time; a fixed cutoff suggests a configured deadline. A connected socket does not prove initialization or tool listing completed. Ask the publisher whether the request reached the handler and produced a matching response.

Raise a configurable request limit only when there is evidence of legitimate bounded work. Increasing a connection timeout cannot change a different request timeout. Avoid replaying writes when the execution outcome is unknown. If the response explicitly says Gateway Timeout, follow HTTP POST failures.

Fix for SDK client and server authors

For TypeScript SDK 2.x, request options are the second argument. This bounded policy follows the REA deadline investigation (opens in a new tab):

const result = await client.callTool(
  { name: 'long_operation', arguments: {} },
  {
    timeout: 120_000,
    resetTimeoutOnProgress: true,
    maxTotalTimeout: 300_000,
    onprogress: ({ progress, total }) => console.log(progress, total),
  },
);

The 1.x SDK placed these options after the optional result schema argument. Check your installed API before copying. REA's follow-up notes the newer SDK labels the failure REQUEST_TIMEOUT.

Server authors should return matching replies, observe cancellation and keep work responsive. In Python SDK 2.x, progress reporting (opens in a new tab) uses injected Context:

import asyncio
from mcp.server.mcpserver import MCPServer, Context

mcp = MCPServer("example")

@mcp.tool()
async def bounded_work(ctx: Context) -> str:
    for step in range(3):
        await asyncio.sleep(1)  # Replace with cancellable asynchronous work.
        await ctx.report_progress(step + 1, 3)
    return "done"

Progress does not automatically extend every host's deadline. The caller must request and handle it, and a maximum total deadline should still bound the operation. Do not emit fake progress to conceal a stuck backend.

Check with mcptest

Test your server shows which stage completes and which request stalls. There is no transport diagnostic id specifically for a request deadline. session.stickiness can reveal failures during bounded session probes; transport.sse-content-type-mismatch catches a related parser failure, not slow execution. Re-run the actual slow operation with the intended host deadline; a successful short ping does not validate it. See stream termination when the connection drops first.