How to control when timeout occurs? #1207

Timeouts are controlled on the client side, not the server side. This is necessary because a misbehaving server may never respond (even if it "meant to").

You may want to consider prefetching the resource, or introducing some kind of multi-step loading, like:

1. Client sends a request. Loading begins, server responds with "in progress."
2. Client polls until loading is complete and/or server sends a notification that loading completed.
3. Client sends a final request, and gets back the actual resource.

Though this question did make me think that we could support auto-extending timeouts when progress notifications are used, which doesn't currently happen.

The original answer is still correct about one important boundary: the server cannot extend a timeout chosen by the client. However, MCP 2025-11-25 added an experimental protocol-native option for this exact class of long-running work: Tasks.

If both sides support it, the flow is now:

1. The server advertises capabilities.tasks.requests.tools.call.
2. The tool advertises execution.taskSupport as optional or required.
3. The client sends a task-augmented tools/call.
4. The server quickly returns a CreateTaskResult with taskId, status, TTL, and polling interval.
5. The client uses tasks/get for status and tasks/result for the eventual CallToolResult.

This prevents the 20–40 second upstream call from having to fit inside one synchronous request timeout, while keeping cancellation, deferred result retrieval, and reconnection semantics in the protocol.

A couple of practical details:

• A missing progressToken is expected when the client did not include one in the request _meta. Progress is opt-in and a server should not assume every client requests or supports it.
• Progress notifications are useful UX, but they do not universally guarantee that a host will extend its request deadline. Do not use them as the only timeout strategy.
• Keep a separate timeout around the external HTTP/resource call inside the server. The client timeout and the upstream timeout protect different boundaries.
• Tasks are still experimental and host support varies. If your target client does not support them, the two-tool fallback remains valid: start_job(...) -> jobId, then get_job(jobId) (and optionally cancel_job(jobId)). Return the first response immediately and store job state outside the request handler.

So the implementation choice is:

• Task-capable client: use MCP Tasks.
• Legacy/non-task client: use the explicit queued-job/status-tool pattern.
• Short, reliably bounded upstream call: a normal synchronous tool call is still fine; configure the client deadline there.

Official references:

• MCP Tasks (2025-11-25)
• Task extension overview and client support
• Progress notifications

We've limited Discussions in this repository to meeting notes and are closing this thread. To continue the conversation, pick a channel from Contributor Communication. Thanks for posting.