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

You point an MCP client at https://evidiq.dev/mcp, you call verify_agent, and instead of a JSON result you get an HTTP 402. The first time this happens, every developer curses. The second time, you realize the 402 is the answer — it's a machine-readable invoice. That tension is the entire reason we built EVIDIQ as an x402 pay-per-call MCP server instead of a normal SaaS endpoint with a Stripe key behind it.

The model context protocol assumes tools are free. They aren't. Some of them should cost real money to call, because the work behind them costs real money — live endpoint probes, on-chain identity lookups, signed reports. So we put the payment rail inside the same HTTP layer MCP already uses. No separate billing API. No accounts. No API keys. Just a 402 challenge, a signed authorization, and a result.

The Wire Protocol, Byte by Byte

An x402 pay-per-call MCP server from EVIDIQ is an MCP endpoint that returns an HTTP 402 Payment Required challenge when a paid tool is called. The client signs an EIP-3009 transferWithAuthorization, retries with the payment header, and EVIDIQ settles on X Layer in USDT0 before running the tool and returning the result.

Here is the literal sequence our MCP server runs when you call a paid tool. Nothing about this is hidden — it's all in the EVIDIQ docs.

1. Client sends a normal JSON-RPC request to POST https://evidiq.dev/mcp with method tools/call, params { name: "verify_agent", arguments: { agent: "..." } }.
2. Our server checks the tool. how_to_install and get_evidiq_skill are free, so it runs them and returns immediately.
3. verify_agent is paid. The server returns 402 Payment Required with a JSON body containing an accepts[] array — exactly one entry for the single price of one verify call.
4. The client parses accepts[], signs an EIP-3009 message off-chain (no gas from the user), and retries the same POST with header X-PAYMENT: <base64 proof>.
5. Our server hands the proof to the settler contract on X Layer. USDT0 moves. The tool runs. The client gets the trust score report.

That's the entire skeleton. Five round trips is the worst case — usually three, because the free tools skip step three. Worth noting: we don't replay the tool's work. The body is hashed at step two, the same arguments are re-validated at step five, and only then is the agent probed and the trust score emitted. The verdict arrives with a recommendation: proceed, proceed_with_escrow, caution, or do_not_proceed.

Reading an accepts[] Object

JSON object, a signed retry with X-PAYMENT header, and a settlement confirmation arrow returning. Dark navy background with cyan, teal, and amber accents. No real brand logos. Developer/tech aesthetic. Abstract indicators only.]

The 402 body is the part that scares people, because it looks like a contract. It isn't. It's a struct describing one payment option. Here is a real one we ship today, lightly trimmed:

{
  "scheme": "exact",
  "network": "x-layer",
  "amount": "10000",
  "asset": "USDT0",
  "payTo": "0xEvId1qSettlerAddress...",
  "extra": {
    "name": "USDTToken",
    "version": "1"
  }
}

Let's walk it field by field, because every field has bitten an integrator we've helped debug.

• scheme — currently always "exact". The x402 spec also defines "upto" for capped streaming, but our settler doesn't accept that today.
• network — the CAIP-2-ish identifier. We use "x-layer". Anything else and the settler won't find the contract.
• amount — a string, not a number, and in atomic units. "10000" is 0.01 USDT0 because USDT0 has 6 decimals. Forget the decimals and you've just sent ten thousand dollars.
• asset — "USDT0" is human-readable; the actual contract address lives in extra in v2 of the spec, which we follow.
• payTo — the settler address, not EVIDIQ's wallet. We never custody funds. Settler is a tiny contract that calls transferWithAuthorization on USDT0 and forwards it to EVIDIQ's payout address.
• extra.name / extra.version — used to compute the EIP-712 domain separator. Get the version wrong and your signature verifies to a different contract address, and the settler rejects you with a domain-mismatch error. We cover that below.

If a client gets amount wrong by misreading decimals, the transaction either under-pays (settler reverts) or over-pays (real money lost, no refund path). Both are visible in the response. The EVIDIQ Operator docs include a worked example in TypeScript, and the EVIDIQ Sentinel docs document every revert string we've seen.

A wallet balance alone tells you nothing about intent — that's the gap the 402 challenge closes. It pins a specific price, a specific asset, a specific window, and a specific recipient to one tool call. Without it, the agent economy is just APIs with extra steps. This is what makes our x402 pay-per-call MCP server practical: every byte in accepts[] has a job, and missing any of them is detectable on-chain.

EIP-3009 Without the Cryptography Lecture

EIP-3009 is transferWithAuthorization. Three actors: a from address (the payer's wallet), a to address (us), a value, a validAfter, and a validBefore. The payer signs an EIP-712 message off-chain that authorizes exactly that transfer. Nobody pays gas to sign.

When our settler gets your signed payload, it calls transferWithAuthorization on USDT0 itself. The contract checks the signature, checks the time window, marks the nonce used, and moves the tokens. One transaction. One block confirmation. Done.

Here's why this matters for an x402 pay-per-call MCP server: the user pays nothing for the signing, only for the settlement. That's why a developer can wire this up in a CI script, an agent loop, or even inside another MCP server without ever funding a gas wallet. USDT0 is the gas token on X Layer, so the settlement fee is also a fraction of a cent — but it isn't paid by you, it's paid by our settler relayer.

We've watched integrations ship and break on the same two things: the EIP-712 domain separator and the chain id. The domain is EIP712Domain(name, version, chainId, verifyingContract). For us that's:

• name = USDTToken
• version = 1
• chainId = 196 (X Layer mainnet)
• verifyingContract = 0x...USDT0

If any of those four is wrong, the signer recovers a different address and the settler reverts with FiatTokenV2_2: invalid signature. We return that error text verbatim in the 402 retry response so your client can fix it. We chose X Layer because USDT0 is the native gas token, which keeps a verify_agent call under one cent total — cheaper than the bandwidth you spent reading this paragraph.

What Happens on a Bad Signature or Late Nonce

Failure paths are where most pay-per-call designs go dark. Ours don't. Every rejection has a reason, and that reason is in the response body. If you're debugging a client, here's the cheat sheet we wish someone had handed us on day one.

• FiatTokenV2_2: invalid signature — almost always a wrong domain separator. Re-derive the EIP-712 hash and check chainId and verifyingContract.
• FiatTokenV2_2: authorization expired — your validBefore was in the past. We default to a 60-second window. If your client took longer than that, sign again.
• FiatTokenV2_2: nonce already used — replay attempt. Our settler rejects duplicates hard. Generate a fresh 32-byte random nonce per call.
• FiatTokenV2_2: invalid receiver — to in the signed message doesn't match the settler. You probably copy-pasted from a different chain's docs.
• HTTP 402 still returned after retry — the X-PAYMENT header wasn't attached, or it wasn't base64-encoded, or the inner JSON wasn't the exact proof shape. We log the parse error server-side; your client gets back a 402 with error: "payment_parse".

One thing we promise — and what we've shipped today — is that no payment is silently lost. If the signature is bad, no tokens move. If the tokens move but the tool fails, the evidence is still recoverable through the EVIDIQ Notary docs, because every report is hashed (keccak256), anchored on 0G Storage mainnet with an on-chain tx, and signed with the EVIDIQ key (EIP-191). You can re-fetch the evidence, re-hash it, and recover the signer. That's the auditable side of the x402 pay-per-call MCP server promise — same inputs, same deterministic score, audience-independent.