Seller's guide · 2026

How to monetize an MCP server

You built an MCP server. Now get paid for it. This page compares the five ways to charge, then shows the mechanics of the one that suits AI agents — the HTTP 402 an agent reads, the signature it sends back — and the five ways we have watched real listings earn nothing.

Last updated: · by FiatDock

The five ways to charge for an MCP server

ModelHow it worksBest forTrade-offs
Pay-per-call (x402)Call returns HTTP 402 with a price; the agent signs a USDC authorization and retriesAI agents; data, lookup and compute toolsAmounts are small, so volume is the game
SubscriptionRecurring fee for access, enforced by a keyHuman SaaS buyers; predictable revenueA signup and a card sit before the first call
Prepaid creditsBuyer tops up a balance, calls draw it downBursty use; human and agent buyersYou hold someone else's money; refunds and expiry are yours
API key + invoicingIssue keys, bill in arrearsEnterprise procurementSlowest to get paid; needs collections
Ads / sponsorshipA third party pays for placement in your outputConsumer-scale volumeYour output stops being neutral; agents are a poor ad audience

The dividing line is not price. It is whether a buyer with no human attached can finish the transaction. A subscription needs someone to enter a card; credits need someone to top up and notice when it runs out; invoicing needs a purchase order. Each is a person-shaped step, and an autonomous agent has no person on hand at 3am. Pay-per-call removes the step instead of automating it — and gives you the least protection from your own downtime, because nobody is on a plan.

Platform terms, checked July 2026: listing directories (Smithery, Glama, mcp.so, PulseMCP) pay developers $0 — they are catalogs, not payment rails. Hosted marketplaces (Apify, MCPize) take a 15–20% cut and pay on a schedule, holding the funds in between. FiatDock takes 0% for 30 days then 1%, split at payment time; the money never lands with us.

What the demand actually looks like

Honest numbers, including the ones that do not flatter us. The traffic hitting FiatDock today is overwhelmingly automated — crawlers, uptime monitors and x402 indexers. That is distribution, not demand, and we will not sell it to you as demand.

The market that matters is the wider x402 ecosystem, and it is smaller than the headlines. Measured on 12 August 2026 over the previous 30 days: $197,149 settled across 523 services. But 86% of that was a single service (BlockRun, $170,244), and only 66 services earned more than $10 all month. The service with the widest buyer base — 1,460 distinct paying wallets — earned $153.

Read those last two together: the service that reached the most buyers did not earn the most money. Cheap, broad coverage attracts paying wallets; a high price does not conjure buyers who were not there. We are not exempt — in the same window FiatDock's own first-party tools took $0.14 from 2 paying wallets, and the third-party marketplace has had no external buyer at all. Listing here puts your server where agents can pay for it. It is not a promise that they will.

How an agent actually pays you

Worth understanding before you price anything: the mechanics explain why the amounts are small and why the buyer needs no relationship with you. x402 is an HTTP payment protocol; the exchange is two requests.

  1. The agent calls, without paying. It gets HTTP 402 Payment Required, with the requirements base64-JSON in the PAYMENT-REQUIRED header and as JSON in the body.
  2. It reads the terms. The accepts array names the network, asset, atomic amount, recipient and the EIP-712 domain needed to sign — a real entry from a live listing here:
{"scheme":"exact",
 "network":"eip155:8453",                   // Base
 "asset":"0x8335…2913",                     // USDC
 "amount":"10000",                          // atomic = $0.01
 "payTo":"0x0B46…55d6",                     // the SELLER's wallet
 "maxTimeoutSeconds":120,
 "extra":{"name":"USD Coin","version":"2"}} // EIP-712 domain
  1. It signs an authorization, not a transaction. An EIP-3009 transferWithAuthorization over that USDC contract — the agent authorizes a transfer, it does not broadcast one.
  2. It retries with the signature in the PAYMENT-SIGNATURE header — the x402 v2 name. The older v1 X-PAYMENT is still accepted here, because breaking installed clients to tidy a header is not an upgrade.
  3. A facilitator submits it and pays the gas. The part people miss: the paying agent needs no ETH, only USDC. The relayer covers gas and never holds the funds.

So read accepts.length rather than assuming one entry: during a seller's 0% first month the 402 lists one leg at the full price straight to the seller, and two after it (99% seller, 1% platform). Leg count changes on a date the buyer cannot see, so the 402 is the authority, not the documentation.

Deliver first, then settle — what it means for you

Most gateways take the money and then do the work. FiatDock runs verify → forward → settle: the payment is verified before your server is touched, your server answers, and only then does the money move. No answer, no settlement, and the buyer is told plainly they were not charged. That cuts both ways.

The guarantee is in the live 402 itself: "You are charged only if the seller actually answers … an answer you merely dislike is still a delivered call, and is paid." That last clause is the seller's protection. Delivery is what we arbitrate; quality is not.

Publishing: what the door actually checks

When you publish, the endpoint is probed live, in that request, before the listing exists. If it cannot answer, the publish is refused — not accepted with a warning nobody reads. The refusal names the cause: unreachable endpoint, no tools exposed, a paid listing that named no tool, a tool absent from tools/list, or an npm package that does not exist.

Two details that save time. When a paid listing names no tool, the refusal lists your server's actual tool names, so filling the field is a paste, not a guess. And POST /v1/marketplace/services?dryRun=1 runs the whole pipeline — validation, live probe, every gate — reports what would happen, and creates nothing.

After publishing the rules loosen deliberately: a live listing is never suspended for a passing outage, and every publish rule is grandfathered on an edit, so a broken listing can always be repaired.

Five ways a listing earns nothing

Every one of these has happened to a real seller here — the list we built warnings for after watching sellers leave.

1 · An npm-package listing

A stdio/npx package runs on the buyer's machine. No call passes through the marketplace, no 402 is issued, nothing to meter — it can never collect. We refuse a price on a package listing rather than let you publish one that cannot earn. Fix: host at a public HTTPS URL, then swap the package name for that endpoint.

2 · A paid listing with no payout wallet

Nowhere to send the 99%, so the gateway answers 409 instead of a price and the agent never sees a 402 — while the listing looks normal in the catalog. Fix: set the payout wallet; it becomes buyable immediately, no re-publish.

3 · Naming a tool your server does not expose

The tool name decides what a payment invokes. If it is not in your server's tools/list — usually a typo, or a rename you shipped later — the call cannot produce an answer. Names are case-sensitive. Fix: re-probe and paste the exact name.

4 · Hosting that sleeps or moves

Free tiers idle out, and tunnel URLs (trycloudflare, ngrok, pinggy, loca.lt) are regenerated every session, so the address in your listing is dead by design — a free Pinggy tunnel lasts 60 minutes. After 7 continuous days of silence a listing is hidden from the default catalog: hidden, not deleted, and one successful check restores it.

5 · A price in your text, not in the field

Writing "$0.01 per call" in the description while the listing is published with priceUsd 0 means agents call it free and you receive nothing. The words are not the price; the field is. Fix: set priceUsd, minimum $0.001.

Pricing your calls

The floor is $0.001 per call, and it is not arbitrary: USDC has 6 decimals and the platform's 1% share is a whole number of them, so below $0.001 the rounding makes the commission far exceed 1% — at $0.000002 it would be 50%. Publishing is refused below the floor rather than overcharging you quietly.

Above it you set what you like, and the honest guidance is the measurement above: real x402 calls have been observed settling in the $0.002–$0.03 band, and the widest buyer base belongs to a service charging very little. Price a lookup like a lookup. If your tool does something genuinely expensive — a model call, a paid upstream API — price to cover it, and expect fewer buyers rather than more revenue.

Your commission is 0% for your first 30 days from the day your seller account is created, then 1%. During the waiver the buyer makes one payment: 100% of the price, straight to you. No listing fee, no monthly fee, no minimum volume.

Why non-custodial matters here

The buyer's payment goes directly to your wallet on Base. The 1% is an atomic on-chain split taken at payment time, not a cut of money we received and forwarded. FiatDock never holds your funds, so there is no payout cycle, no minimum withdrawal and no escrow — and no balance of yours for us to freeze, because there is no balance. Your raw endpoint stays private behind a gateway URL (/s/{id}) and forwarded calls are signed, so your server can accept gateway traffic only. Detail: sell your MCP service · how agents pay with x402.

FAQ

How do I monetize an MCP server?

Host it at a public HTTPS URL, list it with a per-call price, and let agents pay per call. The first call returns HTTP 402 with the price; the agent signs a USDC authorization and retries, and the money settles on-chain straight to your wallet. Keep 100% for your first 30 days, then 99%.

What are the ways to monetize an MCP server?

Five: pay-per-call, subscriptions, prepaid credits, API keys plus invoicing, and advertising. The dividing line is not price but whether a buyer with no human attached can finish the transaction — only pay-per-call lets an agent do that alone.

How much can an MCP server actually earn?

Less than the marketing suggests. Measured on 12 August 2026 over the previous 30 days, the x402 market settled $197,149 across 523 services — 86% of it one service (BlockRun, $170,244), and only 66 services earned more than $10. The widest buyer base, 1,460 paying wallets, earned $153.

How does an agent pay for an MCP call technically?

An unpaid call returns 402 with the requirements base64-JSON in the PAYMENT-REQUIRED header: network, USDC asset, atomic amount, recipient, EIP-712 domain. The agent signs an EIP-3009 transferWithAuthorization and retries with it in PAYMENT-SIGNATURE (X-PAYMENT still accepted). A facilitator submits it and pays the gas, so the paying agent needs no ETH.

What happens if my MCP server fails to answer a paid call?

Nothing settles and you earn nothing; the buyer is not charged either. MCP reports failure at HTTP 200, so the body is read: -32601 and -32700 are the seller's fault and settle nothing, while -32602 is the buyer's bad input and does settle. An answer merely disliked is still delivered, and is paid.

What stops an MCP listing from earning anything?

The five above: a stdio/npm listing, which runs on the buyer's machine and can never collect; a paid listing with no payout wallet, which answers 409 instead of a price; naming a tool your server does not expose; hosting that sleeps or a tunnel URL that moves; and a price in your description while the price field is 0.

Start earning: create your seller account · sell an MCP service · pricing · browse listings.