feat: change resetTimeoutOnProgress default to true#1393
feat: change resetTimeoutOnProgress default to true#1393elango5292 wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
|
@modelcontextprotocol/client
@modelcontextprotocol/server
@modelcontextprotocol/express
@modelcontextprotocol/hono
@modelcontextprotocol/node
commit: |
Long-running MCP tools that send progress notifications should keep connections alive by default. This changes the default behavior so clients automatically reset their timeout when receiving progress updates. Previously, clients would timeout after 60 seconds even if the server was actively sending progress notifications, unless they explicitly set resetTimeoutOnProgress: true.
elango5292
force-pushed
the
feat/default-reset-timeout-on-progress
branch
from
390c144 to
52ef6fb
Compare
|
Closing — await client.callTool({ name: "...", arguments: {...} }, { resetTimeoutOnProgress: true });Changing the default is a behavioral break for every existing client, and it interacts with #1001 (a misbehaving server could hold requests open indefinitely by spamming progress). We'd want to think about both together — probably in a major version, with The real gap here is discoverability — this option isn't in the docs or examples. That's worth fixing. If you want to open a PR adding a long-running-tool example to See #192 for the original discussion. |
2 participants
Summary
Changes the default value of
resetTimeoutOnProgressfromfalsetotrue.Motivation
Long-running MCP tools (like AI research tools) can take 60+ seconds to complete. Servers can send progress notifications to indicate they're still working, but clients currently ignore these by default and timeout after 60 seconds.
This change makes progress notifications actually useful by default - if a server sends progress updates, the client will reset its timeout automatically.
Changes
packages/core/src/shared/protocol.ts: Changed default fromfalsetotrueBackward Compatibility
Clients that explicitly set
resetTimeoutOnProgress: falsewill continue to work as before. This only affects clients that don't specify the option.Cross-SDK Consistency
I understand MCP has SDKs in multiple languages. If this change is accepted, should similar changes be made to other SDKs (Python, Java, etc.) for consistency? Happy to submit PRs to other SDKs if the team agrees this should be the default behavior across all implementations.