Sell your MCP service — get paid per call

List in four steps

Hosted or stdio — pick the one that matches your server

A listing connects agents to your service in one of two ways, and the choice decides whether it can be paid.

• An npm package name — for stdio/npx servers. Agents run your server locally. A stdio server has no network address — it is started as a subprocess and talks over stdin and stdout — and stdio is the default transport in the MCP specification, so a package name is all a listing needs. These listings are free only: nothing routes through our gateway, so there is no call for us to price. Your listing shows the ready npx command.
• A hosted HTTPS endpoint — Streamable HTTP. Required for a per-call price, because the gateway has to forward the paid call somewhere. Your raw URL stays private; buyers only ever see /s/{id}.

If you have a stdio server and want to charge for it, hosting it is the whole gap — see the host-it-to-earn guide.

What the publish check tests

Publishing runs a live probe and refuses if it fails. This is deliberate and it is the one place we fail closed: at publish time you are present and a refusal costs you one attempt, whereas a broken listing accepted silently costs a buyer money and costs you months of nothing happening. The checks:

• Your endpoint completes an MCP handshake — including the session handshake stateful servers require, so a Python FastMCP server on its defaults is read, not reported unreachable.
• It exposes at least one tool.
• A paid listing names the tool the gateway will invoke, and that tool exists on your server. If the name is wrong, the refusal lists your server's real tool names and suggests the closest match — a typo is fixed by pasting, not guessing.
• An npm package resolves on the registry, or npx -y <pkg> would fail on the buyer's machine.

Two things soften it. Add ?dryRun=1 to the publish request to run the entire path — validation, gate, live probe — and be told what would happen without creating anything. And after a listing exists, editing is never blocked by a rule your edit did not create: a seller whose endpoint went down must always be able to change the endpoint URL that would fix it.

What happens on a paid call

In order, every time:

1. The buyer calls POST /s/{id} without payment and receives a 402 naming your wallet as the recipient, the exact amount, the chain and the deadline.
2. They sign and retry. The gateway verifies the payment and claims the authorisation, so one signature can buy exactly one answer.
3. The gateway forwards the call to your endpoint, signed with an X-FiatDock-Gateway HMAC, wrapped in the tools/call envelope for the tool your listing names.
4. It reads your answer. Only then does it settle on-chain — your share first, the platform's 1% second, or a single full-price payment to you during your first 30 days.

Settling after delivery is what lets the marketplace refuse nobody. It used to settle first, which meant protecting buyers from a listing that might not answer required blocking that listing outright — and at one point that was 18 of 36 live listings, every one a seller who could not earn. Now a call that produces no answer simply costs nothing, so nothing has to be blocked.

What counts as answering

Worth knowing precisely, because it decides whether you are paid. MCP over HTTP reports tool failures with HTTP 200, so the gateway reads the JSON-RPC body, not just the status:

• Your fault, nothing settles: method not found, parse error, internal error, and the server-defined -32000 to -32099 range. The buyer gets a 502 and is told they were not charged.
• Buyer's fault, settles: invalid arguments (-32602). If bad input were free, a buyer could farm unlimited calls with junk arguments at your expense.
• Not an answer: a handshake or capabilities blob returned in reply to a tools/call.

Sellers whose servers demand their own registration or API key on top of the buyer's payment fall into the first category — the buyer paid, your server refused, and you both got nothing.

After you publish

Your hosted endpoint is re-read every six hours — hourly if it lives on an ephemeral tunnel host such as *.trycloudflare.com, whose URLs are built to disappear — and, most usefully, the moment you edit the listing: an edit re-probes the endpoint on the spot, so a fix takes effect immediately instead of waiting for the next cycle. Each pass is a security scan of your tools/list against prompt-injection and tool-poisoning rules, plus a health record from the same read. An unreachable endpoint is not suspended — a live listing has flipped healthy and unhealthy inside an hour, so a single failed check means nothing. It affects ordering only. After seven consecutive silent days a listing leaves the default catalog, stays reachable at its own URL and on your dashboard, and returns automatically on one successful check.

To find out whether anyone actually bought, use GET /v1/marketplace/sellers/me/earnings or the headline on your dashboard: settled invokes, exact USDC earned, last sale, and a row per listing. Because we are non-custodial, that page reports what settled to your wallet — not a balance we hold for you. The same authenticated responses carry a notices block naming anything currently stopping your listings from being bought, and the exact fix.

Is there any demand?

A straight answer instead of a promise. As of 13 August 2026, no external buyer has yet paid for a third-party listing on FiatDock. Three real external x402 settlements have landed, all on FiatDock's own first-party data routes, totalling $0.003 across 10 and 12 August 2026 — and both paying wallets paid hundreds of other endpoints that same week, which makes them catalog scanners confirming the paywall works, not customers. Most of the traffic we see is automated: crawlers, uptime monitors, x402 and MCP indexers.

The wider market reads the same way if you divide. In the public CDP Bazaar index on 13 August 2026, one seller of chain primitives had 759 unique payers over 30 days and earned $0.0675 per payer — the identical figure FiatDock earned on 2 payers. A different seller earned $9.98 per payer. Across 20 of one seller's 25 endpoints, calls divided by payers came to exactly 1.00: every wallet called once and never returned. Payer counts largely measure how thoroughly a catalog has been indexed.

So the honest pitch: listing is free, takes minutes, and puts your service in the catalog, the search_services tool, llms.txt, skill.md and the x402 discovery surfaces before buyers arrive — not because they already have. Where the money goes still matters: listing directories such as Smithery, Glama, mcp.so and PulseMCP pay you $0 for a listing, and hosted marketplaces such as Apify and MCPize take a 15–20% cut, hold the funds and pay out on a schedule (named as of July 2026). Here it is 0% for a month, then 1%, on-chain, straight to your wallet.

Frequently asked

Do I need verification to sell?

No — anyone can publish, and the listing is live and discoverable right away. The $20/mo badge is an optional trust mark.

When do I get paid?

Per call, on-chain, as it happens — the payment settles to your wallet once your server has answered.

Is it custodial?

No. Funds move buyer→seller directly via x402; FiatDock holds nothing and takes its 1% as a separate payment.

Can I list a stdio/npx server without hosting it?

Yes, as a free listing pointing at your npm package name. Paid per-call listings need a hosted Streamable-HTTP HTTPS endpoint.

Get started: create your seller account · list in 5 minutes · what an MCP marketplace is · how to choose one · selling an API to agents · pricing.