Skavio x402 MCP: what to verify before replaying a paid request

A timeout after a paid tool call leaves two separate questions: did payment settle, and did the tool complete? A stable idempotency key can help recover one logical operation—but only when the server implements the matching replay contract. For Skavio x402 MCP, the reviewed sources establish the payment flow, not the exact paid-request deduplication behavior. Use this checklist before enabling automatic paid retries.

1. Establish replay support before building the retry loop

Skavio’s canonical MCP endpoint is https://getskavio.com/mcp. Tool discovery and skavio_catalog are free; connecting an ordinary MCP client does not authorize payments. Start with discovery, then inspect the published schema for verify_native_usdc, the single example used here. Before adding payment recovery, confirm whether the service advertises and implements the x402 payment-identifier extension for the intended call. The reviewed Skavio documentation does not establish its accepted idempotency field, cached-response behavior or recovery guarantees. A client-generated key alone cannot supply those server capabilities.

• Confirm the accepted identifier location and the scope within which it identifies one operation.
• Establish how long replay records remain available and how changed arguments are handled.
• Confirm recovery behavior for in-flight requests, expired authorizations and server restarts. Do not infer these details from general x402 support.

2. Persist one operation before attempting payment

Create a durable local operation record before authorizing payment. Associate one generated identifier with the exact tool name and arguments, the relevant account context and the spending approval. After a reconnect or client restart, load that record rather than generating a new identifier inside the retry loop. The x402 payment-identifier extension specifies IDs of 16–128 characters using alphanumeric characters, hyphens or underscores. When the server advertises and supports the extension, the identifier belongs at PaymentPayload.extensions["payment-identifier"].info.id. Preserve the advertised extension structure and add the ID there; do not invent a Skavio-specific header or metadata field.

• Keep the tool arguments unchanged during recovery. Changed inputs are not the same request.
• Do not reuse an operation key for unrelated work.
• Keep the operation key distinct from the JSON-RPC request ID, payment authorization nonce and transaction hash being inspected.

3. Review the challenge before the wallet signs

For verify_native_usdc, separate the transaction being inspected from any payment requested to invoke the tool. Before approving a Base USDC payment challenge, check the requested network, native Circle USDC identity, recipient, amount and authorization conditions against the approved spending policy. Skavio’s documented paid-MCP flow is to receive PaymentRequired, obtain a wallet-authorized payment and retry through params._meta["x402/payment"]. Paid execution requires an x402-aware client; wallet secrets must remain client-side. The payment-identifier extension, if supported, is part of the payment payload carried through that flow—not an alternative payment channel. MCP also changes where the client must look for a payment challenge. The x402 MCP specification places PaymentRequired in an isError tool result. A successful transport exchange therefore does not, by itself, mean the tool succeeded.

• Require explicit spending approval before signing; free discovery is not payment consent.
• Reject an unexpected network, token, recipient or amount.
• Do not interpret a wallet signature as evidence of settlement.

4. After an uncertain response, reconcile before paying again

If the connection drops after submission, retain the same operation record and mark the outcome as uncertain. Do not blindly create another payment authorization or switch to a fresh key to make the error disappear. Follow the service’s documented recovery procedure; if that procedure is unavailable or does not resolve the ambiguity, pause automatic paid retries. The payment-identifier specification defines cached-response recovery for the same identifier and payload, and an HTTP 409 conflict for changed payloads. Those are extension semantics, not verified Skavio MCP error behavior. Do not assume that Skavio returns that HTTP status, retains results indefinitely or exposes an undocumented reconciliation endpoint. When a response is available, examine both the tool output and payment information. The MCP transport specification places settlement-response metadata at result._meta["x402/payment-response"]. Assess tool completion and payment settlement separately, using the evidence actually returned.

• A failed or missing tool response does not establish that no payment occurred.
• Settlement evidence does not establish that the requested tool output is complete or correct.
• An expired authorization is a recovery condition to resolve—not automatic permission to sign another payment.

5. Test interrupted recovery before any funded test

Use mocked responses to exercise failure paths before connecting a funded wallet. The important test is not merely whether a retry succeeds, but whether the client preserves the original operation and refuses to make an unsupported payment decision. Where server replay support is confirmed, validate its documented behavior separately from your local tests. A mock can demonstrate that your client retains a key; it cannot prove that the service deduplicates execution or settlement. Any funded test should require explicit owner approval.

• Lost response: retain the original identifier and arguments without automatically signing again.
• Client restart: recover the durable operation record instead of creating a new one.
• Changed arguments: stop recovery rather than silently treating a different request as the original.
• Concurrent retries: coordinate client attempts and verify the server’s documented concurrency behavior.

Read the Skavio x402 documentation and start with free discovery →