Paid tools create replay surfaces
An MCP tool call can be cheap to repeat but expensive to authorize incorrectly. If a payment proof or receipt can be replayed, a provider may perform extra work without payment or a buyer may be charged for the wrong execution.
Replay protection should be designed before adding real rails. It is much harder to retrofit after a tool has public clients.
Bind the payment to the agreement
The payment or authority reference should include the agreement hash, provider identity, expected tool, amount, asset, deadline, rail and chain domain where applicable.
A proof for one provider or task should not authorize another provider or task, even if the amount is identical.
Use one-time identifiers
Each paid invocation should have a nonce, payment_id or execution id that is stored atomically before work starts. The replay store should reject duplicate use across retries unless the agreement explicitly defines retry semantics.
If the provider supports idempotent retries, the idempotency key should return the same result for the same agreement, not a new paid execution.
Protect the receipt path too
A Verification Receipt should not be accepted if it references a different agreement, output, provider, verifier or execution id. A Settlement Receipt should not be accepted if its rail proof belongs to another chain, asset or task.
Receipt validation is where many subtle replay bugs show up because the payment path and verification path are often implemented by different services.
Test the bad paths
A production checklist should include duplicate payment_id, reused agreement hash with different output, cross-provider replay, cross-rail replay, expired proof, wrong asset, wrong chain and verifier mismatch.
The mock rail demo is the safest place to build those tests before connecting a facilitator, wallet or testnet contract.
FAQ
Is HTTPS enough replay protection?
No. HTTPS protects the transport, but the protocol still needs one-time identifiers and agreement-scoped payment proofs.
Should retries reuse the same payment?
Only if the agreement explicitly allows idempotent retry behavior and the provider returns the same execution result.
Where should replay state live?
In provider-side durable storage or a rail-backed state mechanism strong enough for the payment risk.
Sources and references
Accord/MCP guide
How Accord wraps MCP tool calls with agreement and receipt semantics.
Paid MCP production checklist
Checklist for taking a paid MCP tool beyond a local demo.
Paid MCP repository audit demo
Reference demo for the local mock-rail lifecycle.
Run the paid MCP demo
Test duplicate payment_id, verifier mismatch and agreement replay before real rails.