OpenAPI-generated tools in FastMCP do not execute within an MCP `RequestResponder` context.

[tspicer]

Description

When a client (e.g., Claude) cancels a timed‑out call, FastMCP logs a validation warning and the connection drops. Timeouts are surfaced as unhandled exceptions rather than clean tool errors.

Client Symptoms

• Tool calls hang then fail; on timeout, Claude sends notifications/cancelled,
  after which the session sometimes disconnects.
• Users see intermittent “disconnected” or “no response” after long OpenAPI tool
  calls.

Server Behavior

• Logs show duplicate “Processing request” lines, then warnings like: “Failed to
  validate notification: RequestResponder must be used as a context manager”.
• Timeout exceptions (asyncio/httpx) bubble through OpenAPI tools and are not tr
  anslated into ToolErrors.
• On cancellation, the SDK attempts RequestResponder.cancel() on a responder t
  hat was never entered, triggering the warning and session instability.

Observations

• FastMCP’s OpenAPI tool generation produces callables that do not accept
  /use Context and therefore do not run under RequestResponder.

• Cancellation notifications from the client can’t be matched to an active respo
  nder; FastMCP logs a warning and the transport becomes unstable.

• Timeouts are not handled by the generated tools, so exceptions propagate and c
  an break the MCP session.

• Use FastMCP OpenAPI-generated tool for a slow API call (HTTP transport or stdi
  o).

• Configure client with a shorter tool timeout (e.g., 20–30s).

• Observe: at timeout, client sends notifications/cancelled; FastMCP logs “Req
  uestResponder must be used as a context manager” and the session may disconnect.

Expected vs Actual

• Expected: Tool runs under RequestResponder; cancellation cleanly cancels the
  tool; timeout surfaces as a ToolError without disconnecting.
• Actual: No responder context; cancellation triggers validation warning; timeou
  ts raise exceptions; session may disconnect.

Proposed Fix (FastMCP)

• Ensure OpenAPI-generated tools execute within RequestResponder:
  • Generated functions should accept ctx: Context and use with ctx.request_r esponder() as rr: around the call.
  • Map notifications/cancelled to the active responder so rr.cancel() clean
    ly aborts the call.
  • Catch timeout/cancellation (asyncio.CancelledError, httpx timeouts) and re
    turn a proper ToolError (not a raw exception), preserving the MCP session.
• Optionally, centralize timeout handling in the OpenAPITool layer (wrap __call __) to convert timeouts to ToolErrors consistently.

Temporary Workarounds (confirmed working)

• Add a logging filter to suppress the specific cancellation warning; prevents d
  isconnect but is a band‑aid.
• Wrap OpenAPITool.__call__ to catch timeouts (asyncio.TimeoutError, httpx. TimeoutException, ReadTimeout, ConnectTimeout) and return a structured erro
  r instead of raising.
• Increase client and server read timeouts (e.g., 60–180s) for legitimately long
  calls.

Environment

• FastMCP with experimental OpenAPI parser enabled (FASTMCP_EXPERIMENTAL_ENABLE _NEW_OPENAPI_PARSER=true).
• Server runs both stdio and HTTP transports; issue reproduced in both.
• Client: Claude Desktop sending notifications/cancelled after tool timeout.

Example Code

Version Information

2.12

[jlowin]

Are you absolutely sure about the RequestResponder? I didn't believe it was possible to even enter a tool call without one, as its loaded to process every JSONRPC message with the tool call handler as its payload. You've traced this call into the MCP SDK? The other thing I don't understand about this writeup is that there is no __call__ method on OpenAPITool, and providing a context kwarg is simply sugar, not an alternative code branch. If there is an issue here, it would be more helpful to just understand the issue and an MRE.

[tspicer]

The issue has been difficult to track down and the primary client has been Claude Desktop, so it is possible there is an issue upstream there. The error and disconnect will often occur quickly, meaning after starting the server, then starting Claude next, Claude will may or may not show it is connected, but in about 10 seconds, it will be disconnect and in the in the FastMCP log.

Since I have been focused on the OpenAPI side, this was the scope of my testing. My suspicion was that the issue was unlikely at the server and that client was behaving badly. Force quits of Claude will eventually get it to properly connect.

WARNING:root:Failed to validate notification: RequestResponder must be used as a context manager. Message was: method='notifications/cancelled' params={'requestId': 1, 'reason': 'McpError: MCP error -32001: Request timed out'} jsonrpc='2.0'

Experimented with different Claude configs, but nothing was definitive. The server was running locally as a Docker container.

"amazon_ads_mcp": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "http://localhost:9080/mcp"
      ],
      "env": {
        "MCP_TIMEOUT": "120000",
        "MCP_REQUEST_TIMEOUT": "60000",
        "MCP_CONNECTION_TIMEOUT": "10000",
        "MCP_SERVER_REQUEST_TIMEOUT": "60000",
        "MCP_TOOL_TIMEOUT": "120000",
        "MCP_REQUEST_WARNING_THRESHOLD": "10000"
      }
    },

I will work on trying to better isolate a test tomorrow.

[jlowin]

Claude Desktop has been having a lot of MCP errors this week, we've gotten many reports. I don't know why, unfortunately. If you can produce a reliable MRE, please reopen!