Deadlines, cancellation and unknown outcomes

The mechanism

A deadline limits how long the caller waits and how much work an operation may consume. Cancellation requests cooperation from the execution path; it does not rewind a database commit or recall a sent message. Keep response delivery, worker execution and business effects separate in your state model.

Current HTTP cancellation follows the response-stream lifecycle. stdio has its own notification pattern. Apply the rules for the selected transport rather than treating cancellation as a universal extra RPC. Progress updates can improve the interface, but they must not reset a deadline indefinitely.

ParcelOps reads can usually be retried after transient failures within a budget. A future writer needs reconciliation and destination-side idempotency. The same retry policy should not be applied to both simply because they share tools/call.

Worked example

This application retry table distinguishes four outcomes. The values are planning decisions, not measured latency or protocol defaults. A production implementation should make the maximum attempts and total deadline explicit and observable.

Invalid input       -> stop; ask for corrected input
Denied operation    -> stop; do not broaden permissions
Transient read      -> bounded retry with backoff
Unknown write       -> reconcile using stable business intent key
Cancelled operation -> stop new work; inspect already committed effects

Practice: predict, inspect, explain

Offline exercise. Draw a timeline where the server commits a note at time 4 and the connection closes at time 5 before the response arrives. Mark what the client knows and what the server knows. Repeat with cancellation arriving before the commit.

Expected observation: timing changes which outcome is possible, but the client must not infer rollback from disconnection. Add a maximum elapsed budget across all attempts, including backoff and additional-input rounds. A useful test checks that no new attempt starts after the deadline.

Troubleshooting and trade-offs

If cancellation only closes a browser spinner, backend work may continue consuming resources. Propagate cancellation through handlers and dependencies where supported, and record any operation that cannot be interrupted. If retries amplify an outage, reduce concurrency and apply bounded backoff. Never report a write as failed solely because its response timed out.

Interview practice

Completion check

Explain the commit-before-disconnect timeline and distinguish stopping work from reversing work.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Cancellation
• Official documentation: Progress
• Official documentation: Streamable http