An agent retries a payment tool call after a network blip. The underlying API receives the request twice. The customer's card is charged twice. By the time anyone notices, your support queue has five tickets, your reconciliation report is wrong, and the word ASIC is appearing in Slack.
This is not a hypothetical. An Australian Buy Now Pay Later firm in 2024 faced exactly this scenario. Total remediation cost: roughly $280,000, split across customer credits, support overhead, and ASIC reporting obligations. The MCP idempotency pattern that would have prevented it runs to about 200 lines of code and three days of engineering time.
The four-part MCP idempotency pattern
The fix is not complicated. It is specific. Every MCP tool that mutates state needs four things wired in before the first production retry.
A client-generated idempotency key. The agent creates a UUID before calling the tool. The key travels as a parameter through the MCP call to the underlying API. Stripe, Square, and most modern payment and booking APIs accept this natively.
A result cache with a 24-hour TTL. The MCP server stores the key and its result. On retry, it returns the cached result instead of re-executing. No second charge. No second booking. No second outbound email.
Explicit retry safety signalling in the tool schema. The tool definition tells the model that retries are safe. Claude and other reasoning models will hesitate to retry a tool they believe is not idempotent. If you do not signal it, you give up the benefit of retry logic at the agent layer.
Structured error responses, not exceptions. A failure returns a JSON object with a retryable field and a reason string. Exceptions that surface as ambiguous failures produce unpredictable agent behaviour. Own the retry decision inside the tool.
A Melbourne SaaS team retrofitted this pattern across four production MCP tools and cut their on-call paging volume by 30% in the first month. Most of the wins came from the long-tail failure category: the network blips and timeout cascades that happen at 3am on weekends and previously produced two hours of incident review each time.
The pattern also makes the agent's retry behaviour predictable. Without idempotency, a retry that succeeds still leaves uncertainty: did it fire once, or twice? Operators end up querying the underlying system to reconcile. With idempotency wired in, the answer is always 'exactly once, with this key.' Reconciliation becomes a lookup, not an investigation.
The cost of a single missed retry
The $280,000 figure from that BNPL incident breaks down roughly like this: around $42,000 in customer credits for duplicate charges, around $80,000 in engineering and support time at fully loaded rates of $120-$180/hr for technical staff, and the remainder in ASIC reporting overhead. Under Australian financial services law, a duplicate charge on a credit product is a reportable event. The audit trail requirement does not care that the root cause was a network timeout. The regulator sees the output, not the stack trace.
The same logic applies in insurance, healthcare, and any sector where APRA CPS 230 or the Privacy Act governs how automated systems interact with customer data. APRA CPS 230 requires financial institutions to manage the operational risks from automated processes. A duplicate policy endorsement, a duplicate appointment booking, a duplicate patient notification: these are not minor inconveniences in regulated environments. They are compliance events with paperwork attached, and that paperwork costs time at $200-$400/hr for the professionals who complete it.
Where to wire it in
Payment tools, ticketing systems, calendar booking integrations, outbound email and SMS triggers, CRM record creation, and accounting tools like Xero and MYOB. Any workflow that produces a customer-visible action or financial record should be idempotent by default.
The bar to skip idempotency is high: the operation must be both cheap to repeat and immediately visible to the user if it fires twice. A read-only lookup does not qualify. A tool that creates a Xero invoice does. If you are auditing your existing MCP tools to identify which ones need this treatment, our AI Readiness Assessment is a structured starting point.
When idempotency is the wrong answer
Not every MCP tool needs this layer. Building one for tools that do not need it adds latency, cache overhead, and a maintenance surface for no gain.
The tool is read-only. Queries and lookups cannot double-charge anyone. Skip the cache entirely.
The operation is naturally idempotent. Setting a status flag to active twice produces the same result as setting it once. No extra layer needed.
The action has no customer-visible or financial consequence. Internal logging and debugging tools do not need idempotency wiring.
The mistake is treating idempotency as a checkbox that applies to everything. It is a targeted architecture decision. Wire it where mutations are customer-visible or financially consequential. Skip it where they are not.
The compliance conversation
Every regulated Australian buyer asks the same question during MCP vendor assessment: how does an agent retry interact with your underlying systems? Financial services teams point to ASIC. Insurance buyers mention APRA CPS 230. Healthcare teams cite the Privacy Act. These are not theoretical concerns — they are procurement blockers that hold deals for weeks while a risk committee waits for an answer. Teams that cannot explain their retry model in two sentences spend two months in due diligence instead. Our AI Automation Services include production MCP servers built with full idempotency as a baseline, specifically because Australian regulated buyers need this answer documented before sign-off.
A clear answer closes that line of questioning in one meeting. "Our MCP tools use client-generated idempotency keys with a 24-hour result cache. Retries return the original result. No duplicate side effects." That sentence goes into vendor assessments and does not come back.
Agents were designed to retry. Networks fail, timeouts happen, and LLM calls occasionally stall mid-response. Retry logic is a feature. But a tool that mutates state and cannot safely retry is a tool waiting for its first bad network week. If you are building MCP tools for production use in Australia and want to pressure-test the design before it reaches a regulated customer's procurement review, book a call with our team. Three days of work now. One conversation avoided later.
