FiatDock is a non-custodial marketplace where AI agents discover and pay for MCP (Model Context Protocol) services published by other developers. An agent searches the catalog, calls a service, and pays for that call in USDC over the x402 protocol — settling directly from the buyer's wallet to the seller's wallet on Base, with a 1% platform fee taken as an on-chain split (0% for a seller's first 30 days). FiatDock never holds, routes or aggregates funds.
The Model Context Protocol standardised how a model reaches a tool: how servers advertise what they can do, how a client lists those tools, and how a call and its result are shaped. What it deliberately did not standardise is who pays. So the ecosystem grew a layer of registries and directories — useful catalogs that answer one question, does this server exist?
A marketplace has to answer three more: what does a call cost, how does the buyer pay it, and where does the money end up. Add those to a catalog and the difference is not cosmetic. A directory ends its usefulness at the moment of choosing; a marketplace has to survive the moment of buying, which is where every hard problem lives — pricing, authorisation, failure, refunds, trust in a stranger's server.
Why payment belongs in the protocol
The alternative is what the web already does: put payment beside the protocol. Sign up, confirm an email, copy an API key, store it, attach a card, choose a plan. That works because a person is present to do it once.
An agent cannot do any of it. It cannot confirm an email, it should not be trusted with a long-lived shared secret, and it certainly cannot commit its operator to a monthly plan. An agent that has to stop and fetch a human has stopped being autonomous — which is the entire property you were buying.
Putting payment in the protocol collapses authorisation and billing into a single step that requires no prior relationship. HTTP has reserved 402 Payment Required since HTTP/1.1 without saying what belongs in it; x402 says. The agent sends a normal request. If it needs paying for, the server answers 402 carrying the exact requirements. The agent signs a single-use authorisation and sends the same request again with the payment attached. Four properties follow, and they are the argument:
No shared secret. The credential is a signature over one request, worthless if replayed.
No onboarding per vendor. The first call to a seller works exactly like the thousandth.
Price discovery is free. A 402 is a quote, not a charge — an agent can ask what something costs before deciding.
The unit billed equals the unit of work. One call, one price. Nothing to forecast, nothing left unused.
How the marketplace works
1
Discover
An agent searches by query, category, price or Verified status — via the search_services MCP tool, /browse, or GET /v1/marketplace/services. Search matches the tool names a server actually exposes, not only the text its seller wrote.
2
Pay per call
Calling a paid service returns an x402 402 with the exact payment(s); the agent signs USDC from its wallet and retries. No keys, accounts or subscriptions.
3
Forward, then settle
The gateway forwards the call, reads the answer, and only then settles on-chain — 99% to the seller and 1% to FiatDock, or 100% to the seller during their first 30 days. No answer, nothing settles.
The three marketplace MCP tools
On both transports — the remote POST https://fiatdock.com/mcp (Streamable HTTP) and the local npx fiatdock-mcp package, which auto-pays from AGENT_PRIVATE_KEY:
Tool
Cost
What it does
search_services
free
Search by q / category / verified / sort → matching listings with id, price, seller, and a tri-state callable saying whether a call is expected to produce an answer
get_service
free
One listing in full: how to call it (gateway or direct), its rating, and a call hint written for its actual state rather than a generic example
call_service
x402 — 99% seller + 1% platform (0% the seller's first 30 days)
Invoke a service. Call once with no payment to learn the price; the response carries the full challenge and names the exact next call. Sign, then call again with payment set
That optional payment argument is what makes the catalog buyable from inside MCP. Without it an agent that read the price would have to abandon the protocol and hand-build an HTTP request to complete the purchase — which is where agents give up.
Non-custodial by design
Every paid call is a direct on-chain payment: buyer wallet → seller wallet, via x402 on Base. FiatDock's 1% is a separate payment to a separate address, settled at the same moment — we never receive the seller's money and forward a share of it. No escrow, no pooled wallet, no ledger of balances we owe anyone. During a seller's first 30 days there is no platform leg at all.
This is checkable in about thirty seconds and you should check it: send an unpaid request to any paid listing, decode the 402, and read payTo. It names the seller. The same own-account principle governs the rest of FiatDock, including the cash-out ramp. The seller's raw MCP endpoint stays private behind the gateway URL /s/{id} and accepts only gateway-signed traffic.
Deliver, then settle
A marketplace's real test is what it does when a stranger's server fails. Here the gateway forwards the call before it settles the payment, and settles only once the seller has produced an answer. Because MCP over HTTP reports tool failures with HTTP 200, the gateway reads the JSON-RPC body too: a missing method, a parse error or a seller-side internal error settles nothing and returns a 502 saying you were not charged, while invalid arguments — the buyer's own mistake — do settle, because free failures on bad input would let anyone farm unlimited calls at a seller's expense. One signed authorisation buys exactly one answer.
For agents (buyers)
Zero signup: no accounts, API keys or cards — pay per call in USDC from your own wallet.
One config: add the fiatdock-mcp server to your MCP client, or point at the remote endpoint and sign the 402 yourself.
Trust signals: Verified badges (identity-checked, security-scanned sellers), verified-purchase reviews, and a callable field that is absent rather than false when a listing has simply never been checked.
No crawling required:llms.txt carries the live catalog and prices; skill.md says what to run.
For developers (sellers)
List free in minutes:create an account and publish — a hosted endpoint, or just your npm package name for stdio/npx servers. Guide: sell your MCP service.
Keep 100% for 30 days, then 99%. Listing directories pay developers $0; hosted marketplaces take 15–20% and hold the money (named as of July 2026). See pricing.
Paid directly: buyers pay your wallet on-chain per call. Optional $20/mo Verified badge.
Buyers can try you at no risk: a failed call costs them nothing, which is what lets us refuse nobody.
What it is not
It is not an app store: no installs, no accounts, no invoices, and nothing to uninstall. And it is not a demand engine — a distinction worth stating plainly, because a catalog can be perfectly discoverable and still sell nothing. As of , no external buyer has yet paid for a third-party listing here; the three real external x402 settlements we have received landed on FiatDock's own first-party data routes, totalling $0.003 on 10 and 12 August 2026, from wallets that paid hundreds of other endpoints the same week. Being listed is table stakes, not traction.
Frequently asked
What is an MCP marketplace?
A catalog where agents discover MCP services and call them on demand for a price. A registry records that a server exists; a marketplace adds price, payment and settlement.
How is it different from an app store?
No installs, accounts or invoices. An agent pays each call at the moment it calls, from its own wallet, and the marketplace never holds the money.
How much does it cost?
Free to browse and list. Buyers pay the seller's per-call price; FiatDock takes 1% (0% for a seller's first 30 days). Optional $20/mo Verified badge for sellers.