Client::callTool() does not accept a cancellation signal or a per-call timeout. Applications cannot abandon an individual tool call when a user cancels it without closing the connection or waiting for the configured request timeout.
Expected behavior
- Accept an optional cancellation token and per-call timeout.
- Check interruption before sending, after synchronous I/O returns, and after a suspended request resumes.
- Discard interrupted results, clear pending state, and keep the connection usable.
- Send
notifications/cancelled over STDIO and legacy HTTP. For HTTP protocol 2026-07-28, use response-stream closure.
- Log cancellation-notification failures without replacing the original interruption.
Async behavior and limitations
The client API remains synchronous. Cancellation is cooperative; this proposal does not add an async API, event loop, or framework-specific HTTP client.
- STDIO: cancellation and deadlines are checked while polling for responses. An interrupted request sends
notifications/cancelled.
- HTTP: checks run when control returns from blocking PSR-18 requests or PSR-7 body reads. Cancellation cannot interrupt a wait for headers or the next body chunk.
- Legacy HTTP: a best-effort cancellation POST can itself block. Delivery failures are logged without replacing the original interruption.
- HTTP
2026-07-28: cancellation uses response-stream closure rather than a separate notification.
Per-call deadlines are not hard HTTP wall-clock limits. Applications still need network timeouts on their HTTP client. An async-capable underlying client does not change this when accessed through its synchronous PSR-18 interface.
Cancellation discards the result locally, but does not guarantee that server-side work stops or rolls back.
Client::callTool()does not accept a cancellation signal or a per-call timeout. Applications cannot abandon an individual tool call when a user cancels it without closing the connection or waiting for the configured request timeout.Expected behavior
notifications/cancelledover STDIO and legacy HTTP. For HTTP protocol2026-07-28, use response-stream closure.Async behavior and limitations
The client API remains synchronous. Cancellation is cooperative; this proposal does not add an async API, event loop, or framework-specific HTTP client.
notifications/cancelled.2026-07-28: cancellation uses response-stream closure rather than a separate notification.Per-call deadlines are not hard HTTP wall-clock limits. Applications still need network timeouts on their HTTP client. An async-capable underlying client does not change this when accessed through its synchronous PSR-18 interface.
Cancellation discards the result locally, but does not guarantee that server-side work stops or rolls back.