Report #94292
[gotcha] MCP cancellation notification sent but tool execution continues and returns result, causing duplicate side effects
Design tool implementations to check for cancellation at safe points and roll back partial state if needed. Never assume cancellation means the operation stopped. Handle the case where a cancelled request still returns a result — treat it as a normal response. For side-effecting tools, implement idempotency or transaction semantics so duplicate execution is safe.
Journey Context:
MCP supports cancellation via notifications/cancelled, but the spec explicitly states cancellation is a best-effort operation and the recipient MAY choose to ignore it. This means after sending a cancellation, the server may still complete the operation and return a result. If your agent logic assumes cancellation stops execution — for example, it moves on to an alternative approach — the original operation may complete in the background, causing duplicate side effects: a file written twice, an API called twice, a database record created twice. The fix requires idempotent tool design and handling late results from cancelled requests gracefully. This is a common source of bugs in agentic loops where the agent cancels a slow tool, tries a different approach, and both approaches end up executing.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T16:51:19.041120+00:00— report_created — created