You can build an MCP server in an afternoon. Making one that gets paid is a different problem, because MCP has no billing concept and HTTP has a status code nobody uses. Here is the handshake that actually works, and the parts that broke when I shipped it.
Context, disclosed: I run a paid crypto-intel MCP server (16 tools, USDC per call on Base, no signup). The numbers below are measured on it, including the unflattering ones.
tools/call is a JSON-RPC method over a transport. Nothing in the spec says who is allowed to call, how often, or what it costs. That is fine for local servers that run with your own privileges, and useless the moment the tools cost money to answer.
Three options exist:
x402 uses the one HTTP status code the web never implemented: 402 Payment Required. The server answers an unpaid request with the price and the destination in a payment-required header; the client settles in stablecoin; the client retries the same request with proof.
$ curl -i "https://your-host/mcp" -H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"some_paid_tool","arguments":{}}}'
HTTP/2 402
payment-required: <base64 {scheme, network: eip155:8453,
asset: USDC, amount, payTo, resource, nonce}>
content-type: application/json
{"price_usd":"0.02","pay_to":"0x…","network":"eip155:8453"}
A paying client does exactly three things: read the challenge, settle it through a facilitator, retry with X-PAYMENT. Fifteen lines in most SDKs. No account, no key exchange, no human.
Two implementation rules I would tattoo on the codebase:
Keep the 402 byte-identical to your middleware. If your framework emits a payment-required header and you also write a JSON body, both must describe the same price, asset and address. Clients parse one or the other, and the first time they disagree you get a support ticket that reads like a protocol bug.
Price belongs in the challenge, not the code. Changing a price should be a config edit, not a deploy — and you will change prices once you see what agents actually buy.
1. Not everything should be paid. I made one tool free (akari_board — a live edge board) and it is the only thing that reliably produces repeat traffic. A free, genuinely useful tool is the demo; the paid tools are the product. Making all 16 paid cut discovery to nothing.
2. Discovery is the whole game. Listing in two registries and publishing a machine-readable catalog (/market.json, prices and schemas, no HTML) moved more traffic than any announcement. A beautiful endpoint nobody can find earns zero — and agents find endpoints through catalogs and MCP registries, not landing pages.
3. Idempotency beats dashboards. Your buyers are programs that retry. A call that double-charges on retry is worse than a call that fails loudly. Put a nonce in the challenge, dedupe the settlement, and make the retry safe.
Roughly a month in: three external buyers, $0.06 total, against 16 tools. A public survey of listed x402 sellers shows the same shape across tens of thousands of listings — a median price near $0.03, most earning nothing, and a handful taking the majority of volume.
I am telling you that because the interesting part is not the protocol. It is that the protocol works, the plumbing is boring in the best way, and the entire difficulty is distribution and price. Machine payments have arrived; the market for them has not caught up yet.
/market.json and /llms.txt; list in every honest directory before adding a 17th tool.
Poking at mine, free: market.json, the board, the MCP endpoint. The server itself is MIT: github.com/edvyno/akari-x402-mcp.