Skip to content

callServerTool: opt into progress-based timeout reset#600

Open
anthroy wants to merge 1 commit intomodelcontextprotocol:mainfrom
anthroy:rl/call-server-tool-progress-opt-in
Open

callServerTool: opt into progress-based timeout reset#600
anthroy wants to merge 1 commit intomodelcontextprotocol:mainfrom
anthroy:rl/call-server-tool-progress-opt-in

Conversation

@anthroy
Copy link
Copy Markdown

@anthroy anthroy commented Apr 4, 2026

Problem

A host may interpose a long-running, human-in-the-loop step between the guest's tools/call and the server's response. During that wait, the base SDK's DEFAULT_REQUEST_TIMEOUT_MSEC (60s) in Protocol.request() fires and the guest surfaces -32001 Request timed out, even though the host is still working and will eventually deliver the result.

Change

callServerTool now defaults onprogress to a no-op and resetTimeoutOnProgress to true. This causes Protocol.request to:

  • include _meta.progressToken in the outgoing request
  • reset the 60s timer when a notifications/progress arrives for that token

Hosts can then heartbeat (notifications/progress) during long-running interposed steps to keep the request alive. Tool calls are the request type expected to be long-running, so this is the right layer to opt in. Callers can still override both options.

No behavior change for hosts that don't send progress — the no-op handler just makes the SDK able to receive heartbeats.

Hosts may interpose long-running steps (e.g. inline OAuth on 401) between
the guest's tools/call and the server's response. Without this, the base
SDK's 60s DEFAULT_REQUEST_TIMEOUT_MSEC fires and the guest sees -32001
even though the host is still working.

Passing onprogress causes Protocol.request to include _meta.progressToken
in the outgoing request and register a progress handler; resetTimeoutOnProgress
makes incoming notifications/progress reset the per-request timer. Hosts can
then heartbeat during human-in-the-loop steps. Callers can still override both.
@anthroy anthroy marked this pull request as ready for review April 4, 2026 02:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant