Skavio x402 MCP: Read PaymentRequired before signing a payment
A PaymentRequired response is a checkpoint for reviewing payment terms—not permission to spend. Before an x402-aware client creates a payment authorization for a Skavio x402 MCP tool, verify the requested resource, service-fee recipient, network, token and amount. Keep tool discovery, wallet authorization, settlement and tool output separate.
1. Find the challenge in the MCP result
Skavio publishes its MCP endpoint at https://getskavio.com/mcp. Tool discovery and skavio_catalog require no payment; paid execution requires an x402-aware client. Connecting an ordinary MCP client does not authorize wallet spending. For this inspection workflow, keep automatic signing disabled and review the unsigned challenge first. Skavio documents a call to a paid tool without payment returning PaymentRequired. Under the x402 v2 MCP transport specification, the tool result has result.isError set to true, with the PaymentRequired object in result.structuredContent. The same object is JSON-encoded in result.content[0].text. Prefer structuredContent when parsing; an isError flag alone does not identify a payment challenge. Keep this separate from the HTTP transport. An HTTP 402 response carries a base64-encoded PaymentRequired object in the PAYMENT-REQUIRED header, and the signed retry uses PAYMENT-SIGNATURE. HTTP header decoding is not MCP tool-result parsing.
- Check for a recognizable PaymentRequired object rather than treating every tool error as a request for money.
- Stop before any signer or automatic payment wrapper runs.
- Check the current Skavio documentation and a fresh unsigned response; do not treat an upstream example as a captured Skavio challenge.
2. Match the offer to the intended resource and merchant
Start with x402Version: it should be 2 for this workflow. Next, inspect resource.url and compare it with the resource you intended to access. A well-formed challenge is not sufficient if it points to an unexpected resource. Also confirm the intended tool name and business arguments before proceeding. Review the options in accepts rather than blindly choosing accepts[0]. Inspect scheme, network, amount, asset, payTo, maxTimeoutSeconds and any extra fields required by the selected scheme. Reject malformed or unsupported options. Compare the proposed terms with trusted merchant configuration and your spending limits—not merely with other values in the same response. For Skavio’s inspection tools, distinguish the tool’s recipient argument from the challenge’s payTo. The former identifies the transfer recipient being checked; the latter identifies the recipient of the service fee. They serve different purposes and must not be substituted for one another.
- Resource: does resource.url match the approved resource?
- Payment method: does the client support the scheme and its required extra fields?
- Merchant: does payTo match an independently approved service-fee recipient?
- Budget: does the proposed amount fit the per-call limit and remaining workflow budget?
3. Verify Base USDC, then decode the amount
Skavio documents the service-fee payment chain as Base mainnet, eip155:8453, regardless of which blockchain the tool is inspecting. Inspecting another chain does not move the service fee to that chain. Base Sepolia, chain ID 84532, is a different network—not an interchangeable testing label. Check network and asset together. Circle lists native Base-mainnet USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. A displayed “USDC” label does not replace checking the token contract on the selected network. The amount field is a string of atomic token units. USDC uses six decimal places: an illustrative amount of "12500" means 0.0125 USDC. This is a decoding example, not a Skavio price quote. Parse and compare amounts using integer arithmetic; convert to a human-readable decimal for display. Avoid floating-point comparisons in the approval decision. Do not interpret the challenge’s token amount as a promise of zero additional fees. Review any fee information disclosed by the client before approving.
- Require the expected payment network, not merely a network supported by the wallet.
- Verify the native USDC contract rather than trusting a token name or symbol.
- Display the decoded amount alongside its atomic-unit value and compare it with an integer-denominated spending cap.
4. Approve what the wallet will actually sign
Reviewing the challenge is only the first half of the signing checkpoint. The authorization constructed from it must match the approved terms. For an EIP-3009 exact-EVM authorization, inspect from, to, value, validAfter, validBefore and nonce, together with the token’s EIP-712 domain information. Confirm that from identifies the intended payer wallet, to matches the approved payTo, and value matches the selected amount. Check that the signing domain corresponds to the intended chain and token contract. This checklist applies to that authorization scheme; it is not a claim that every payment scheme uses the same fields. Do not read maxTimeoutSeconds as an absolute expiry timestamp: it is a payment-completion limit. The authorization’s validity fields require their own review. Present a concise approval summary before invoking the signer: operation, resource, Base network, token, service-fee recipient, amount and authorization validity. Obtain explicit wallet-owner approval before any signer or automatic payment wrapper runs. A mismatch should stop signing, not trigger a best-effort guess.
- Reject and investigate an authorization that differs from the approved terms.
- Keep private keys, seed phrases and signed payment payloads out of examples and public logs.
- Treat a signature as an authorization that can be submitted for settlement—not evidence that a transfer has already settled.
5. Retry the intended call, then reconcile payment and output
After approval and signing, Skavio documents retrying the intended tool call with the payment payload in params._meta["x402/payment"]. Preserve the intended tool and its business arguments; adding payment metadata is not a reason to change what the user approved. Inspect result._meta["x402/payment-response"]. The MCP specification defines settlement information including success, transaction and network fields. Review the returned evidence and check the referenced transaction against chain data where available. A signature alone is not settlement evidence. If the request times out, do not assume nothing was paid. The exact-EVM specification allows settlement_pending when a transaction has been broadcast but confirmation cannot yet be established. Reconcile the existing attempt before creating another authorization. This is a recovery precaution, not a guarantee against duplicate payment. Finally, validate the tool output against the original request. Payment settlement and correct execution answer different questions. Neither a signed challenge nor an on-chain transfer, by itself, establishes a customer sale.
- Track the payment attempt separately from the tool’s execution result.
- Reconcile unknown or pending settlement before authorizing another payment.
- Check that the output concerns the requested chain, transaction and inspection parameters.