Skavio x402 MCP: explaining x402 to an HTTP API team
Skavio x402 MCP provides read-only native Circle USDC inspection, with conditional per-call payment in native USDC on Base. For a team accustomed to HTTP APIs, the starting point is familiar: request a resource, inspect the response and decide what to do next. The difference is that a payment challenge requires a spending decision—not an automatic retry. Keep tool discovery, payment authorization, settlement and the delivered result separate.
1. Start with discovery, without authorizing spending
Begin at the documented MCP entry point, `https://getskavio.com/mcp`, which uses Streamable HTTP. MCP separates `tools/list`, which discovers tool names and input schemas, from `tools/call`, which invokes a named tool with arguments. In Skavio’s published contract, tool discovery and the `skavio_catalog` tool require no payment; `verify_native_usdc` is a paid tool. This gives the team a useful first exercise: inspect the available tools and understand their inputs before connecting a payment-capable signer. An ordinary MCP client connection does not provide x402 payment capability or authorize spending. Paid execution requires an x402-aware client capable of signing payments. Skavio does not request wallet private keys.
2. Treat HTTP 402 as a negotiation step
Use Skavio’s documented HTTP endpoint as the concrete example: `GET /x402/v1/usdc/verify`, with `tx_hash` and `network` parameters. The requested resource is an inspection result for an existing transaction. Paying for that inspection is a separate operation: the selected inspection network does not change the documented fee-payment network, Base (`eip155:8453`). In x402 v2’s HTTP transport, a request requiring payment receives HTTP 402 and a base64-encoded `PaymentRequired` object in the `PAYMENT-REQUIRED` header. Do not build a client that depends on finding the challenge in a JSON response body. After spending approval, the client retries with a `PaymentPayload` in `PAYMENT-SIGNATURE`; settlement information is conveyed through `PAYMENT-RESPONSE`. The protocol distinguishes the client requesting access, the resource server providing it and the facilitator role that verifies payment and handles settlement. Payment verification and settlement are distinct stages. Both are separate from inspecting the transaction identified by the tool’s `tx_hash` argument.
- PAYMENT-REQUIRED: inspect the payment requirements before making a spending decision.
- PAYMENT-SIGNATURE: submit the payment payload through the documented retry flow.
- PAYMENT-RESPONSE: read the settlement information separately from the resource output.
3. Put a spending policy between the challenge and the signer
A readable challenge is not permission to pay it. Decode and validate the requirements before invoking a signer. Start with `x402Version`, the requested `resource` and the available options in `accepts`; then inspect the details of the option the client proposes to use. For a first integration, make approval explicit and human-controlled. Later automation should operate within an approved spending policy rather than treating every valid-looking challenge as an instruction. MCP’s tools specification recommends human oversight and confirmation controls.
- Check `scheme`, `network` and `asset` against the published contract and your approved configuration. Verify token identity, not just a displayed USDC label.
- Check `amount` and `payTo` against the authorized spend and recipient. Amounts are expressed in atomic token units, not automatically in human-readable dollars.
- Review `maxTimeoutSeconds` against the published contract. Set bounded retry and spending limits in your client, and reject unexpected requirements rather than silently adapting the wallet configuration.
- Keep the inspection network and payment network visibly separate in the approval screen. Selecting another supported inspection network does not move Skavio’s documented fee payment away from Base.
4. Translate the flow into MCP—not into HTTP payment headers
MCP’s use of HTTP transport does not mean its tool-level payment contract uses the HTTP payment headers above. Under the x402 MCP transport specification, payment requirements appear inside the tool result. A client must understand that structure before it can complete the paid call. The conceptual sequence remains recognizable: call the tool, inspect the requirements, approve payment and retry through the documented mechanism. The message locations change. A generic MCP client may discover the tool successfully while still lacking the payment support needed to execute it.
- Challenge: the tool result has `isError: true`, with `PaymentRequired` in `structuredContent` and matching JSON text in `content`. Check for that documented structure; do not treat every error result as a request to pay.
- Retry: the payment payload goes in `params._meta["x402/payment"]`.
- Settlement information: read `result._meta["x402/payment-response"]`.
- Do not substitute `PAYMENT-SIGNATURE` or other HTTP payment headers for this MCP metadata contract.
5. Check settlement and the inspection result independently
Do not compress the whole interaction into one “paid” flag. A signed authorization alone is neither a successful settlement response nor a completed resource delivery. The core protocol permits different execution and settlement ordering by payment flow, so avoid assuming that every implementation follows one universal sequence. For Skavio’s verification example, examine the settlement information separately from the inspection output. Check that the output corresponds to the transaction hash and inspection network originally requested. Successful payment does not, by itself, establish that the resource output is complete or suitable for downstream use. If a connection fails after signing or retrying, report an unresolved state rather than immediately authorizing another payment. Reconcile the available payment and request evidence using the published documentation. If that evidence does not resolve the state, stop for review before attempting another payment. Use bounded retries, and do not assume exactly-once charging, automatic refunds or an undocumented Skavio idempotency guarantee.