The MCP Inspector client's request timeout mechanism does not reset when a notifications/progress message is received for an ongoing request. This deviates from a suggested behavior in the MCP specification, potentially causing premature timeouts for long-running operations that provide progress updates.

Specification Reference:

The MCP specification document basic/lifecycle.md under the "Timeouts" section states:

Implementations MAY choose to reset the timeout clock when receiving a [progress notification] corresponding to the request, as this implies that work is actually happening. However, implementations SHOULD always enforce a maximum timeout, regardless of progress notifications, to limit the impact of a misbehaving client or server.

Current Behavior:

In client/src/lib/hooks/useConnection.ts, the makeRequest function initiates a setTimeout when a request is sent. This timeout is only cleared when the request promise resolves or rejects (within the finally block). Receiving a notifications/progress (handled separately via setNotificationHandler) does not interact with or reset this timeout timer.

Expected Behavior:

Following the suggestion in the specification, the client could reset the request timeout timer each time a relevant notifications/progress is received. This would allow long-running operations that provide regular progress updates to continue without timing out prematurely, as long as progress is being reported within the timeout window. A maximum overall timeout should still be considered.