Research · Paid MCP · 12 September 2026
How to monetize an MCP server with x402
MCP tells a client what tools exist and how to call them. It does not, by itself, decide who may spend money or how settlement happens. In 2026, the clean pattern is to keep MCP as the tool layer and put a machine-readable payment gate around the valuable call.
Short answer
To charge per MCP tool call with x402: expose the tool, declare a price and payee, return a 402 payment requirement before execution, verify the signed payment, execute once, return the result plus settlement evidence, and publish enough discovery metadata for compatible buyers to find the tool before they pay.
Paid MCP is an overlay, not a new MCP protocol
The Model Context Protocol has evolved its own lifecycle, tools, resources, authorization and extension system. Payments remain a separate concern. That is a useful boundary: an MCP host can discover and invoke a tool without being given unrestricted financial authority, while a payment client or wallet can enforce its own budget and counterparty rules.
Cloudflare's current Agents SDK makes the separation concrete. Its x402 integration wraps an MCP server with withX402 and exposes paidTool for priced calls. An unpaid invocation returns a payment challenge; after verification, the tool runs and the result is returned. Free and paid tools can coexist on the same MCP server.
The six-part seller flow
- 1. Price the outcome. Charge for a tool whose output has enough value or upstream cost to justify a paid call. Publish the price before execution.
- 2. Keep the live payment contract explicit. The buyer needs the amount, asset, network, recipient and scheme from the current challenge, not from stale marketing copy.
- 3. Verify before expensive work. A payment gate should sit ahead of the paid operation so an invalid or unpaid request cannot consume the valuable resource.
- 4. Execute once. Use idempotency, nonce or replay controls appropriate to the rail and operation. A network retry is not permission to charge or fulfil twice.
- 5. Return verifiable delivery. The paid response should match the documented schema and be attributable to the requested operation.
- 6. Make the service discoverable. Publish MCP metadata, human documentation and machine-readable service/payment information. Monetization without discovery is just a closed toll booth.
x402 vs MPP for a paid MCP server
| Question | x402 | MPP |
|---|---|---|
| Typical fit | Per-request machine payments with an HTTP 402 challenge and programmatic settlement. | Machine payments with charge, session or subscription intents and multiple payment methods. |
| MCP relationship | Cloudflare currently supports paid MCP tool calls directly through its x402 Agents SDK integration. | Cloudflare documents MPP payment challenges for MCP tools over the same client/server separation. |
| Seller decision | Useful when an agent-native pay-per-call contract is the commercial unit. | Useful when the seller needs broader payment methods or recurring/usage-based payment intents. |
Testing before mainnet
Cloudflare's current x402 MCP guide recommends testing on Base Sepolia before moving to Base production. That is the right place to prove the unpaid challenge, payment retry, verification, single execution and result schema. Mainnet is where independent buyer money becomes economically meaningful; test payments are not customer revenue.
Also test the negative cases: wrong recipient, wrong network, insufficient payment, replayed proof, malformed inputs, timeout after settlement and a second retry after a successful delivery. Monetization is a state machine, not a price badge.
Discovery is part of monetization
A paid tool cannot convert a buyer that never finds it. The official MCP Registry is the primary MCP publication layer; downstream directories and marketplaces can expand reach. Keep one provider-owned source of truth for the endpoint and capabilities, then distribute that truth without creating conflicting versions of the same server.
For a paid service, publish enough machine-readable information for a buyer to compare outcome, schema, price, payment rail and provenance before spending. A directory listing is discovery evidence. It is not evidence of usage or revenue.
How zFinia applies the boundary
zFinia's public MCP surface is challenge/handoff oriented and does not present itself as a buyer wallet. Paid machine utilities live on explicit x402 routes with provider-owned agent, x402 and OpenAPI discovery. That keeps tool discovery separate from financial authority while still giving agents a path from discovery to a paid API call.
Current sources
A paid MCP server is not an MCP server with a wallet hidden inside it. It is a useful tool with a verifiable commercial gate, a bounded payment path and a discoverable contract.