Monetize your MCP server in 10 minutes.
Let AI agents pay your MCP server per call, in USDC, with signed webhooks and audit logs. x402-compatible. Drop-in middleware.
You built an MCP server. Thousands of clients are using it for free.
You shipped your MCP server because Claude Desktop, Cursor, and Cline clients needed the capability. Word spread. You are now serving thousands of paid-tool invocations per day from AI agents you have never met. Your egress bill is real. Your API key for the underlying service is real. Your maintenance time is real. The revenue is zero.
You have three options. Keep it free and burn money on infrastructure. Gate it behind manual API keys (and lose 95% of agent traffic to the friction of signup forms). Or add a payment layer that AI agents can actually complete - which is exactly what 402 Payment Required + USDC is built for.
Blockchain0x is option three. Your MCP server points at our API. When an AI client calls a paid tool, the response is 402 with a hosted payment URL. The client (or its human supervisor) pays in USDC. Your webhook fires. The next call from that client succeeds. The whole shape is called x402, and it is the protocol Coinbase published for this exact pattern.
How 402 Payment Required becomes a programmatic checkout.
The HTTP status code 402 has existed since the spec was first written but never had a standard implementation. Coinbase's x402 protocol finally gives it one. The shape is simple: your tool returns a 402 challenge (a structured JSON body describing how to pay); the client pays and retries; the call succeeds. requirePayment from @blockchain0x/mcp builds that challenge body for you.
{
"error": "payment_required",
"amountUsdc": "0.02",
"payTo": "0xYourMcpAgentAddress",
"hostedUrl": "https://pay.blockchain0x.com/checkout/docs-search",
"network": "mainnet",
"description": "docs search"
}The four states
- Unpaid call: AI client invokes a paid tool. Your handler checks your own paid-state, finds the payer is not marked paid, and returns the 402 challenge body from requirePayment as a tool error.
- Payment: Client follows the hostedUrl to the hosted checkout and completes the USDC transfer on Base (either programmatically via an x402-aware wallet or manually via QR code).
- Webhook: Blockchain0x fires payment.received to your endpoint within seconds of chain confirmation. You verify it with webhooks.verify and record the payer as paid in your own store.
- Retry: Client retries the original MCP tool call. Your handler now sees the payer marked paid, runs the tool, and returns the actual result.
Every payment is recorded in your Blockchain0x dashboard, and every payment.received webhook lands in your own logs. Because you own the paid-state and the webhook handler, per-tool and per-payer revenue analytics fall out of the data you already store.
A complete working example.
requirePayment from @blockchain0x/mcp builds the 402 challenge; webhooks.verify from @blockchain0x/node verifies the confirmation. You own the two small pieces in between: the paid-state check inside the tool, and the webhook handler that marks a payer as paid. Below is a complete MCP server that exposes one paid tool plus its webhook endpoint.
import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { requirePayment } from "@blockchain0x/mcp";
import { webhooks } from "@blockchain0x/node";
const server = new McpServer({ name: "docs-search", version: "1.0.0" });
// You decide who counts as paid. Back this with Redis/Postgres in production.
const paid = new Set<string>();
server.tool(
"search_docs",
"Semantic search across our docs",
{ query: { type: "string" }, payer: { type: "string" } },
async ({ query, payer }) => {
if (!paid.has(`search_docs:${payer}`)) {
// Not paid yet: build an x402-compatible 402 challenge and return its
// body as a tool error. requirePayment is a challenge builder - it does
// not gate the call for you; this check is yours.
const { body } = requirePayment({
amountUsdc: "0.02",
payTo: "0xYourMcpAgentAddress",
hostedUrl: "https://pay.blockchain0x.com/checkout/docs-search",
description: "docs search",
});
return { content: [{ type: "text", text: JSON.stringify(body) }], isError: true };
}
const results = await runVectorSearch(query);
return { content: [{ type: "text", text: JSON.stringify(results) }] };
},
);
// Your webhook endpoint marks a payer as paid once the checkout settles.
const app = express();
app.post("/webhooks/blockchain0x", express.raw({ type: "*/*" }), (req, res) => {
const r = webhooks.verify({ headers: req.headers, rawBody: req.body, secret: process.env.BLOCKCHAIN0X_WEBHOOK_SECRET! });
if (!r.ok) return res.status(400).json({ code: r.code });
if (r.eventType === "payment.received") {
// Resolve (tool, payer) from the reference you encoded in hostedUrl, then:
paid.add("search_docs:0xPayer");
}
res.json({ received: true });
});Setup steps
- 1Create a Blockchain0x agent wallet for your MCP server, on a plan that includes API and webhook access. Note the wallet address you will use as payTo.
- 2Install the packages:
npm install @blockchain0x/mcp @blockchain0x/node - 3Set environment variables: BLOCKCHAIN0X_API_KEY (the MCP server sends it as Authorization: Bearer) and BLOCKCHAIN0X_WEBHOOK_SECRET (the dashboard signing secret webhooks.verify checks against).
- 4Gate your paid tools by checking your own paid-state and returning the requirePayment challenge body when the caller has not paid. Leave free tools ungated.
- 5Configure the webhook endpoint in the Blockchain0x dashboard (for example /webhooks/blockchain0x), then verify every delivery with webhooks.verify and mark the payer as paid on payment.received.
- 6Deploy. The first AI client that hits your paid tool gets a 402, pays, and the next call succeeds. You see the payment in the dashboard within 10 seconds.
You can also run the Blockchain0x MCP server itself with npx @blockchain0x/mcp (stdio) or the hosted Streamable HTTP container at mcp.blockchain0x.com. Full setup, including the webhook payload shapes, is in the documentation.
The single most important decision in your handler.
Because you own the paid-state, you also decide how long a payment counts. After a client pays for a tool, keep them marked paid for some window of time, and inside that window let calls through without a fresh payment. Set the window too short and you punish clients with payment friction on every call; set it too long and you give away expensive operations after one cheap payment. A TTL on your Redis/Postgres key is the simplest way to implement it.
The windows we recommend
| Tool type | Window | Why |
|---|---|---|
| Cheap lookup ($0.01-$0.05) | 60 seconds | Absorbs natural retries and follow-up calls without giving away a session. |
| Mid-priced inference ($0.10-$1) | 30 seconds | Pay per call is the right shape; the brief cache handles retry on transient errors. |
| Expensive long-context ($1-$10) | 0 seconds (no cache) | Each call is its own paid event; no caching. |
| Subscription-style tools | 24 hours | Pay once per day for unlimited calls within the window. Higher revenue per client at lower friction. |
Key your paid-state per (payer wallet, tool) pair, the way the example does with search_docs:0xPayer. Two different clients hit the same tool, each pays separately. Same client hits two different tools, two separate payments required. You can scope it more broadly (per payer across all tools) if you prefer; the per-payer per-tool granularity is what makes the pricing feel fair.
Four pricing shapes that work for MCP servers.
Pricing is your call - you set the amount per tool in the middleware. Below are the four patterns we see most often and which tool shapes they fit.
Per-call micro-pricing
$0.01 - $0.05 per callSearch, lookup, classification, format conversion - cheap operations with high volume.
Lowest friction for clients; aligns cost with usage exactly.
Highest transaction overhead; only works at high call volume.
Per-call mid-pricing
$0.10 - $1.00 per callLLM inference, generation, content production, anything where each call does real work.
Balanced - clear value per call, manageable transaction count.
Higher friction per call; clients sometimes prefer subscriptions at this price point.
Per-call high-pricing
$1 - $10 per callLong-context generation, document processing, multi-step orchestration, expensive third-party API wrapping.
Margin per call is meaningful; failed payments are tolerable losses.
Clients negotiate hard at this price; expect refund requests.
Subscription window
$5 - $50 per 24h window (or $X per month)Clients who make many calls in a session and would not tolerate per-call payment friction.
Higher revenue per client; less per-call overhead.
Lower discoverability; clients must commit upfront. Often combined with per-call for hybrid pricing.
Many operators mix patterns: cheap tools at per-call micro-pricing, expensive tools at per-call high-pricing, plus a 24-hour subscription window for heavy users. Nothing stops you running all three on the same MCP server; each tool sets its own amountUsdc in requirePayment and its own paid-window in your handler.
Pro is the right plan for almost every MCP server.
MCP server operators almost always start on Pro because API write access and webhooks are required from day one: Free is read-only, and a paid tool needs to receive payment.received webhooks and verify them. See the pricing page for the exact per-agent cost and where the transaction-fee tiers sit; the short version is that any server doing real paid volume is well past the point where Pro pays for itself.
- Free: useful for experimenting with the API and the dashboard. Not viable for production paid tools (read-only, no webhooks).
- Pro: the default for live MCP servers. Full API access, webhooks, exports.
- Business: when you need the audit log for compliance, or when you run MCP servers for multiple clients and want per-agent team-seat sharing.