Without stream resumability, a dropped response stream now loses the in-flight request, and the client must reissue it as a new request. That is harmless for reads, but dangerous for actions that send money, email, or provision resources. An idempotency key lets the server recognize a retry and suppress duplicated side effects when transport failures occur.
Why retries become dangerous once the stream is no longer resumable
When a response stream can no longer be resumed, a transport drop does not just interrupt delivery, it also destroys the client’s in-flight request context. The only safe assumption is that the client may resend the operation from scratch. That is fine for read-only lookups, but it becomes hazardous the moment the tool can trigger a side effect that must happen once and only once.
For that reason, side-effecting MCP tools need a stable replay marker. The tool invocation itself may be repeated because the network failed, but the server still has to distinguish a fresh request from a retry of the same logical action.
What idempotency keys actually protect
An idempotency key gives the server a durable way to recognize duplicate attempts for the same logical operation. If the first request succeeded but the stream dropped before the client received confirmation, the second request should not create a second payment, send a second email, or allocate a second resource.
This matters because many MCP tools are not merely data fetches. They may change state in downstream systems, and duplicate execution can produce real-world harm even when the underlying network failure was accidental. The key turns a transport retry into a controlled replay instead of a second business action.
The useful mental model is that the key scopes the operation, not the transport. The server should be able to answer, “Have I already performed this exact action?” even when the original response was lost.
Which MCP tool patterns need the strongest protection
Idempotency is most important for tools that create or mutate external state, especially when the effect cannot be inferred or reversed cheaply. That includes payment initiation, message delivery, ticket creation, resource provisioning, approval workflows, and any tool that triggers another system to do work on behalf of the caller. The same retry hazard shows up in the MCP authorization specification, where request handling and token boundaries matter because the server is acting on a caller’s behalf.
A tool that is technically “safe” on a second execution can still need the key if the server cannot prove that property ahead of time. In practice, teams should treat every side-effecting tool as unsafe by default until they have explicitly designed for retries, deduplication, and replay handling.
That is also why agent-oriented guidance stresses tool misuse and identity and privilege abuse: once a tool can act, the main failure mode is often not the initial call, but repeated or redirected calls with the same authority. OWASP Agentic AI Top 10 is useful here because it frames tool-driven systems around exactly those execution risks.
What good implementation looks like in practice
Good idempotency design starts with a client-generated key that is stable across retries for one logical action and unique across distinct actions. The server should store the first successful outcome, associate it with the key, and return the same result for later duplicate attempts within the retention window. Where the action has an external side effect, the response should make it clear whether the first attempt already committed.
What to verify: the key must cover the full business operation, not just the API call envelope. If a retry can change the recipient, amount, destination, or target resource, the key is too narrow and will not prevent duplication. If the tool can be called concurrently, the server also needs an atomic check-and-record path so two near-simultaneous retries do not both execute.
Decision rule: if the tool can create, send, approve, or provision something that survives beyond the request, require idempotency by default. If the tool is read-only, a key is usually unnecessary unless the implementation still has hidden side effects such as logging, billing, quota consumption, or delayed job creation.
Risk and Threat Considerations
Without resumability, the retry problem shifts from a transport nuisance to a correctness and abuse problem. A dropped stream can cause the same side-effecting request to execute more than once, and attackers or buggy clients can exploit that behavior to multiply impact, drain resources, or create duplicate downstream actions.
Failure mechanism: the client cannot recover the original in-flight request context after a stream drop, so it reissues the operation as a new request. If the server lacks replay detection, both executions can commit independently.
Impact: duplicate payments, duplicate emails, duplicated records, repeated provisioning, and inconsistent state across downstream systems. In a tool-driven workflow, that can also create audit confusion because the retry may look like a separate legitimate action unless the server records and returns the original outcome.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Retries of side-effecting agent tools can repeat unintended actions. |
| ASI03 — Identity & Privilege Abuse | Duplicate tool execution can amplify authority and side effects. | |
| Recommendation — Require idempotency for any tool that can mutate external state. Bind each action to a stable request identity and suppress duplicate commits. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Duplicate or replayed requests must be rejected or normalized before execution. |
| SC-23 — Session Authenticity | Lost streams and retried operations need strong request continuity and anti-replay handling. | |
| Recommendation — Validate replay markers and reject repeated side-effecting operations. Preserve request continuity so retries cannot masquerade as fresh actions. | ||
| OWASP API Security Top 10 | API4 — Unrestricted Resource Consumption | Duplicate retries can waste resources or trigger repeated costly work. |
| Recommendation — Cap repeated submissions and de-duplicate expensive operations. | ||
Practitioner Guidance
What to prioritise: classify MCP tools by side effect first, not by how convenient the retry path is. The moment a tool can change money, messaging, access, or infrastructure state, idempotency becomes a core safety control rather than an optional optimisation.
What to verify: confirm that retries reuse the same idempotency key, that the server persists the first committed result, and that the deduplication window matches the real retry behavior of your client and transport. If the server cannot safely retain keys long enough to cover expected retries, the design is incomplete.
Practitioner takeaway: stream resumability failure turns “retryable” into “potentially duplicative,” so the real control is not avoiding retries, but making repeated execution provably collapse to one committed side effect.
