Simulation only. Nothing executes. This example uses an ordinary, non-task tools/call request under MCP revision 2025-11-25 over Streamable HTTP.
A client asks a fictional tool to append one marker to a record. Its JSON-RPC request ID is 7. The server opens an SSE stream, the client receives event cursor e17, and then the connection drops. No tool response reaches the client.
Did the marker get added?
- Yes
- No
- Cannot tell
Reveal
Cannot tell. Two simulated histories fit the same client evidence: the server may have failed before appending the marker, or it may have appended the marker and then failed before delivering the response.
Three identifiers, three different jobs
The JSON-RPC request ID correlates a response with its request. It is not an application-level deduplication key, and this MCP revision prohibits the requestor from reusing an ID within the same session.
Where the server supports resumability, a client can reconnect with an HTTP GET carrying Last-Event-ID: e17. The server may then replay messages missed after that cursor. This resumes the stream; it is not another tool invocation. Resumption is optional, and disconnection is not cancellation.
MCP 2025-11-25 resumability and redelivery rules
An idempotentHint annotation is still only a hint about behaviour. It does not enforce idempotency, and an annotation from an untrusted server must be treated as untrusted.
Official MCP guidance on tool annotations
Practical takeaway
Before repeating a side-effecting operation, establish the tool's actual retry contract or inspect authoritative operation state. If neither is available, preserve the uncertainty. A missing reply does not mean nothing happened.
This is a synthetic teaching exercise, not a live tool run, MCP client/server compatibility test, universal retry guarantee, or evidence that Eggcracker supports MCP. Reader comprehension and independent use have not been measured.