I Put 76 APIs Behind x402-over-MCP — and an Agent Paid for One

# ai# mcp# web3# webdev
I Put 76 APIs Behind x402-over-MCP — and an Agent Paid for OneDataRebelHQ

AI agents are getting good at calling tools. They're still bad at paying for them. An agent can't...

AI agents are getting good at calling tools. They're still bad at paying for them.

An agent can't fill in a pricing page, can't manage a subscription, and shouldn't be holding your API keys. What it can do is sign a transaction. So if I want to sell data to agents — and I do — the payment primitive has to be per-call, machine-native, and settled before the data moves. That's x402: the long-dormant HTTP 402 status, revived as a protocol where the server answers an unpaid request with a payment challenge, the client pays, retries with proof, and gets the data.

I'm Mo. I run ExchangeRebel: 24 pay-per-call API services — 79 paid operations over plain HTTP — covering Solana token safety scores, SEC fundamentals, FINRA short interest, ETF distributions, US macro data, UK company records, product recalls, trademark search, weather, news timelines, a stock screener, and a pile of developer utilities. Every call is priced in USDC on Solana, from $0.005 to $0.50. No accounts, no API keys, no subscriptions: the payment is the authorization.

This post is about the newest front door: one remote MCP server that exposes 76 of those operations as tools, payable through the standard x402-over-MCP transport. It's live, it's listed on the Official MCP Registry and Smithery, and on October 14, 2026 it took its first settled call. Here's how it's built, what conformance actually cost, and where it honestly falls short.

The problem: agents don't do checkout flows

Every monetization pattern built for humans breaks for agents. Subscriptions assume a person who logs in monthly. API keys assume a person who signs up, stores a secret, and rotates it. Prepaid balances make the seller a custodian of buyer funds — I don't want to hold anyone's money, ever.

A per-call payment flips all of that. The server quotes a price in the protocol itself. The client pays exactly that, once, for exactly one call. Settlement is the access control. If the payment doesn't settle, the data doesn't move — fail-closed, no exceptions, no free tier hiding anywhere.

The architecture: the gateway holds zero payment logic

The MCP server lives at https://exchangerebel.com/mcp — one stateless Streamable HTTP endpoint on the same worker as the rest of the fleet. Stateless matters: no sessions, no server-initiated streams, nothing to keep alive between calls.

The design decision I'd make again: the gateway contains no payment logic of its own. Each of the 24 underlying services already had a toll gate — code that builds the x402 challenge, verifies a payment, settles it, records it in a ledger, and only then serves data. Those gates had already survived two full-catalog payment sweeps over HTTP. Reimplementing settlement inside the MCP gateway would have created a 25th payment path to audit.

So the gateway is a translator. An unpaid tools/call gets its challenge built from the target operation's existing challenge — and the gateway proxies nothing upstream, because proxying an unpaid call would be a free-data side door. A paid call has its payment payload re-expressed as the standard payment header and is proxied to the tool's own toll gate, which runs the exact code path an HTTP buyer hits: discriminate the rail, precheck, replay-check, verify, settle, record, serve. The gateway then translates the HTTP response back into a tool result and attaches the receipt.

How does a gate know which rail a payment belongs to? By the transaction's fee payer. A Dexter-facilitated payment carries Dexter's fee payer (DeXterR2kQm8AvRHnNPatWkE46TfAcMeBDjb6FySoAb8); a PayAI payment carries PayAI's. The gate checks Dexter first, then PayAI, then the direct rail — one discriminator, no guessing from payload shapes.

Replay protection is layered the same way: each rail keeps its own settlement ledger, and the gateway adds its own serve-once marker keyed by the hash of the payment bytes, so the same payload can't be served twice through MCP either.

The payment flow, in MCP terms

The x402-over-MCP transport mirrors the HTTP flow, just moved into _meta:

  1. The client calls a tool with no payment. The server returns a tool result with isError: true carrying the PaymentRequired payload — price, asset, network, the works. This is the MCP equivalent of HTTP 402.
  2. The client builds and signs the payment, then retries the same call with the payload at _meta["x402/payment"].
  3. The server verifies and settles, serves the data, and returns the result with the settlement receipt at _meta["x402/payment-response"]. 
// 1. Unpaid call
{ "jsonrpc": "2.0", "id": 1, "method": "tools/call",
  "params": { "name": "devutils_time_now", "arguments": {} } }

// → result: { "isError": true, "content": [ /* PaymentRequired:
     0.005 USDC, Solana, pay to the toll gate */ ] }

// 2. Retry with payment attached
{ "jsonrpc": "2.0", "id": 2, "method": "tools/call",
  "params": { "name": "devutils_time_now", "arguments": {},
    "_meta": { "x402/payment": { /* signed x402 payload */ } } } }

// → result carries the data, plus the receipt:
// "_meta": { "x402/payment-response": { /* settlement receipt */ } }
Enter fullscreen mode Exit fullscreen mode

Client-side wrappers already exist (@x402/mcp on the TypeScript side, a Python equivalent), so an agent framework that speaks this transport runs the whole loop transparently. And the catalog stays free: tools/list returns all 76 tools with full input schemas and the price stated in every tool description, so an agent — or its spend policy — knows the cost before calling. All tools are paid; prices run $0.005–$0.50 USDC per call, and results are served only after payment settles.

What conformance cost

Two line items dominated.

Dual x402 conformance. The fleet speaks both protocol versions: v1 in the response body, byte-identical to what existing v1 clients expect, and v2 in the PAYMENT-REQUIRED header. All 79 paid operations pass as both. That's not vanity — different catalogs and facilitators read different versions, and MCP's transport assumes exactly the standard v2 payload. The conformance work done for HTTP is what made the MCP wrap cheap.

The price floor. Third-party facilitators charge per settled call — PayAI runs about $0.00145 a settle. Price a tool at $0.001 and you lose money on every sale. So the fleet floor is $0.005 per call: 54 of the 76 MCP tools sit exactly there, and the rest price up to $0.50 by data cost and value. Dexter, for the record, settles free — but the floor is set by the rail that charges, because the seller doesn't choose the buyer's rail.

The proof

Sweeps prove a rail works when I pay myself: PayAI settled 74 of 74 catalog buys, Dexter 79 of 79, each verified from the workers' own settlement ledgers rather than client-side success messages.

The MCP proof followed the same rule. On October 14, 2026, the first paid MCP call ran from a real wallet through the Dexter rail: devutils_time_now, $0.005, served with paid_via: dexter. I didn't trust the client's success screen — I read the server-side counter in KV (mcp:count:2026-10-14:settled), which had moved from 0 to 1. First settled MCP call, verified from the server's books.

The honest footnote: every settle so far, on every rail, is my own test money. The first payment from a wallet that isn't mine is still ahead of me. That's what the listings are for.

Honest gaps

  • The direct rail doesn't exist over MCP. Our HTTP API has a third rail — pay directly with SOL or USDC plus a fresh memo, retry with the transaction signature. That dialect is fleet-specific and simply not expressible in the standard MCP transport, which carries the facilitator-settled v2 payload. MCP buyers get PayAI and Dexter; the direct rail stays HTTP-only, and the docs say so plainly.
  • Generic MCP clients stop at the challenge. A client that doesn't speak x402-over-MCP calls a tool, receives PaymentRequired, and has no idea what to do with it. That's protocol-correct behaviour, but it means the MCP server by itself doesn't create demand — discovery does. The registry listings, the catalogs, and posts like this one are the actual distribution.
  • Two tools change the real world. Telegram bot provisioning ($0.50, allocates a bot for a month) and trademark watch registration ($0.50, 30 days) settle once and say so in their descriptions. Idempotency isn't a nicety there; it's the product.

Where it's listed

If you build agents: what would yours pay $0.005 for, per call, without asking you first — and what's missing from a catalog like this that would make it pay more?