How EVIDIQ's x402 Pay-Per-Call MCP Server Actually Works

Your agent just tried to call a paid MCP tool. Instead of a friendly JSON response, the server sent back HTTP 402 Payment Required with a small, slightly cryptic challenge body. Your client threw an exception. The pipeline stalled. Sound familiar?

We've watched this exact moment play out over and over in 2026 as more teams wire AI agents into paid services — and the gap is almost always the same: nobody wants to write the boring integration doc. So we wrote this one the way we wish someone had written it for us back when we were building our own client: a literal byte-by-byte walkthrough of what EVIDIQ's x402 pay-per-call MCP server does on the wire, what each field means, and how to debug it when something goes sideways.

The Wire Protocol, Byte by Byte

An x402 pay-per-call MCP server is an MCP endpoint that returns HTTP 402 Payment Required with an accepts[] challenge before executing a paid tool call. EVIDIQ exposes its MCP server at evidiq.dev/mcp under this model: the skill and install helpers are free, while verify_agent costs a per-call USDT0 price settled on X Layer via EIP-3009.

The full handshake is four steps. Here's the round-trip your client makes against EVIDIQ's x402 pay-per-call MCP server at https://evidiq.dev/mcp:

1. Discovery. Your MCP client — Claude Desktop, an agent harness, your own code — opens a session and lists tools. how_to_install and get_evidiq_skill come back as free. verify_agent is flagged as paid.
2. First call. Your client invokes verify_agent with the agent identifier it wants checked. We respond with HTTP 402 Payment Required and a JSON body shaped per x402 v2: { "accepts": [ ... ] }. The body lists every payment option we accept (in practice one — USDT0 on X Layer).
3. Sign and retry. Your client signs an EIP-3009 transferWithAuthorization message off-chain, packs it into an X-PAYMENT header (base64-encoded JSON per the spec), and re-sends the exact same JSON-RPC tool call.
4. Settle and respond. Our settler verifies the signature, checks the nonce, broadcasts the on-chain transfer on X Layer, waits for the receipt, then returns the 200 OK with the full trust report — score, breakdown, evidence hash, signed verdict.

The whole paid round-trip typically lands in under a second on a healthy X Layer block, dominated by confirmation time. We use the same X Layer RPC we publish for integrators, so retries land on the same mempool and you don't pay for re-broadcasts you didn't make. If anything in step 2 or 3 looks unfamiliar, the next two sections break each piece down.

Reading an accepts[] Object

The accepts[] array is where most first-time integrators get tripped up. Here's the actual shape our EVIDIQ docs describe, and the role each field plays:

• scheme — always the string "exact". It tells the client the price is a fixed amount, not a streaming bid or a quote.
• network — "xlayer" (sometimes written as the CAIP-2 id eip155:196). This is what tells the client which chain to sign against. Sign it for the wrong chain and the settler rejects the signature outright.
• amount — a string-encoded integer in the smallest unit of the asset. For USDT0 with 6 decimals, a 0.10 price shows up as "100000". Off-by-decimals here is the single most common bug.
• asset — the ERC-20 contract address of USDT0 on X Layer. Don't substitute the mainnet USDT address; the chain id in network is your anchor.
• payTo — EVIDIQ's settlement address. We never hold funds long; the settler forwards them to a treasury multisig.
• extra.name and extra.version — a human-readable service identifier and schema version, so a client can sanity-check it's talking to the right EVIDIQ tool before signing anything.

One more field worth flagging: extra.mimeType if we return binary evidence, and the optional outputSchema hint that lets the client pre-validate the eventual report shape. Miss any of these and the protocol is forgiving — you'll either get a clean 402 again or a 400 invalid_payment_request, both of which are debuggable from the body alone.

EIP-3009 Without the Cryptography Lecture

The reason we picked EIP-3009 for EVIDIQ's settlement is not nostalgia. It's that transferWithAuthorization lets the payer sign an off-chain message that authorizes a transfer, while a separate on-chain actor — in our case, EVIDIQ's settler contract — actually executes it. The payer never has to hold X Layer gas. That's a huge deal when the payer is an agent key that exists only to call paid APIs.

Concretely, the message your client signs has six fields: from, to, value, validAfter, validBefore, and nonce. The EIP-712 domain separator binds it to the USDT0 contract on X Layer (chain id + contract address), so a signature for mainnet USDT won't satisfy our settler even if the address matches. Your wallet or signer library fills in validAfter = now - 60s and validBefore = now + 300s by default; we recommend honoring those defaults rather than widening them, because tighter windows reduce replay risk. Our settler is idempotent on the nonce, so a network hiccup that drops your retry is safe — re-signing with the same nonce will not double-charge, because the second attempt will hit the nonce_already_used path and you'll know exactly what happened.

On our side, the EVIDIQ Operator docs walk through exactly how the settler verifies the signature, calls transferWithAuthorization on USDT0, waits for the X Layer receipt, and only then releases the trust report. The contract returns the canonical receipt hash; the report is hashed with keccak256; together they're anchored on 0G Storage with a mainnet tx, and the verdict gets an EIP-191 signature from the EVIDIQ key. That's the same pipeline we built the EVIDIQ Sentinel docs to expose to integrators who want to verify our work independently.

What Happens on a Bad Signature or Late Nonce

We've spent a lot of time on these failure paths because nobody writes blog posts about them and yet every integrator hits at least one. Here's what we return, and why:

• validBefore already passed. You signed the message too long ago, or your clock is skewed. We reply 402 with body { "error": "authorization_expired", "validBefore": <ts> }. Shorten your sign window or sync NTP.
• validBefore is too far in the future. The signer enforces a server-side cap (5 minutes). Going wider returns 402 with { "error": "validity_window_exceeded", "max": 300 }. This is deliberate — we don't want indefinite bearer authorizations.
• Nonce already spent. EIP-3009 nonces are one-shot on-chain. Replaying an old header returns 402 with { "error": "nonce_already_used" }. Always generate a fresh 32-byte random nonce per attempt.
• Wrong domain separator. You signed for USDT on Ethereum mainnet instead of USDT0 on X Layer. The EIP-712 hash differs and our settler rejects it with { "error": "invalid_signature", "reason": "domain_mismatch" }. Double-check network and asset before signing.
• Value below amount. A signed authorization for less than the price. We reply 402 with { "error": "insufficient_value", "expected": "100000", "got": "50000" }.

For verify_agent specifically, we also surface a sixth case: the agent you're checking has no resolvable identity anchor at all. That's not a payment error — it's a clean 200 OK with a trust score in the do_not_proceed band and a recommendation explaining why. Which, honestly, is the whole point. The x402 pay-per-call MCP server exists precisely so your agent can refuse to transact with that one.

If you want to verify any of the failure responses yourself, the canonical report is hashable, the receipt is on-chain, and the verdict is recoverable from the EVIDIQ signing key — full instructions live in the EVIDIQ Notary docs.