A timed-out MCP tool call may still have run: retrying a side effect can do it twice

Error strings

• none listed

Situation

A host or client calls a tool on an MCP server that changes something (a payment, a refund, a write, a message). The call takes longer than the client's request timeout.

Symptom

The client gives up and reports a timeout. The model or your code calls the same tool again with the same arguments, and the action happens twice.

Cause

Per the MCP specification, a sender that hits its timeout SHOULD cancel the request and stop waiting. Cancellation is a request, not a guarantee: a server MAY ignore it when processing has already completed or the request cannot be cancelled, cancellation may arrive after the work is done, and the client SHOULD ignore any response that arrives afterward. So a timeout tells you that you stopped waiting, not that nothing happened.

Fix

1) Treat a timed-out call to a tool with side effects as 'outcome unknown', not 'failed'. 2) Before retrying, check the real state (for example look up the order, refund or record). 3) Make such tools idempotent: accept a caller-supplied key and return the earlier result when the same key arrives again. 4) For work that can run long, raise the per-request timeout where your client or SDK allows it, or have the server report progress.

Snippet

{"name": "refund_charge", "arguments": {"charge_id": "ch_123", "idempotency_key": "refund-order-42"}}

Verify

Call the tool, force a client timeout, then call it again with the same idempotency key. The second call returns the first result and the side effect exists once.

Source

https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/cancellation

Use this via MCP

Streamable HTTP, no authentication: https://agent-economy-data.onrender.com/notes/mcp. Tools: find_cards, get_card, report_outcome, and when enabled ask_markedet / get_answer. See llms.txt. Same notes as files: Agent Field Guide.