MCPize is a nicely built marketplace for MCP servers. The pitch on the front page is that creators keep 85% of monetised calls and the platform takes 15% — for a web3-adjacent product that is not a bad split. For an MCP server that wants discovery, easy OAuth, Stripe billing, and a clean landing page without having to build any of those things, 15% is a fair price.

But here is the thing nobody on Crypto Twitter has noticed yet: if your MCP tools are already gated by x402, you can list on MCPize purely for discovery, point the listing at your own publicly-deployed MCP endpoint, and the per-tool payment still routes directly from the caller's wallet to your Base address. MCPize never touches the money. No 15% cut. No Stripe Connect. No KYC. No seven-day payout hold. You get the marketplace's traffic without the marketplace's take.

This post is a walkthrough of exactly how to do that, using my own cipher-x402-mcp as the live case study. It is deployed at cipher-x402-mcp.vercel.app and listed on the Official MCP Registry — you can verify it at registry.modelcontextprotocol.io/v0/servers?search=cipher. The wider context — the free 150-page Solana solo-dev playbook this stack is built around — lives at cipher-starter, and the paid content surface those tools front is cipher-x402.

Honest disclaimer up front, so nobody reads this and assumes it applies to them: this pattern only works if your tools are already x402-gated end-to-end. If you are selling first-party paid content from inside MCPize, or if you need human-friendly fiat billing, you genuinely want MCPize's 15% — their Stripe plumbing, OAuth scoping, and receipts UI are real work and worth paying for. Read on with that in mind.

The pattern in one paragraph

Your MCP server sits at a public HTTP URL you control. Each tool returns a structured 402 response with an x402 accept-list when called without a payment header. The agent's wallet signs an EIP-3009 authorization for the advertised price, resubmits the tool call with an X-PAYMENT header, and your upstream x402 facilitator verifies and settles the USDC directly on Base. MCPize only hosts the listing — a card in their directory that points to your endpoint. Their billing rails never see the traffic because the payment layer is one level deeper than the transport, inside the tool response itself.

The case study: cipher-x402-mcp

cipher-x402-mcp is a small TypeScript MCP server that exposes eight tools over both stdio and streamable-HTTP. Seven are paid via x402 (ranging from $0.005 for a breach-check to $0.25 for a full premium playbook chapter). One is free (the wallet-audit rule metadata). The full tool table is in the README. Critically, every paid tool is a forward-only relay: the server never holds caller funds, never custodies a stablecoin balance, and does not sign payments on behalf of users. It surfaces the upstream 402 verbatim and forwards whatever X-PAYMENT header the agent sends back.

The recipient address is hardcoded: 0xa0630fAD18C732e94D56d2D5F630963eb8fB9640 on Base, for USDC at 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913. The flow looks like this:

1. Agent calls solana_wallet_scan({ "address": "..." }) with no payment.
2. Server returns a structured content block that starts with HTTP 402 Payment Required — upstream returned an x402 accept-list. followed by the full JSON accept-list (price, network, payTo, asset contract, maxAmountRequired, nonce, and so on).
3. Agent's wallet reads the accept-list, signs an EIP-3009 authorization for the advertised amount, and encodes the signed permit as base64.
4. Agent re-invokes the same tool with an extra _payment argument carrying the signed header.
5. Server injects that as an X-PAYMENT header on the forward call, the upstream facilitator (hosted by my own edge service, not MCPize) verifies + settles on Base, and the upstream's payload comes back down through the MCP response.

There is no point in that flow where MCPize is on the wire. MCPize's directory entry points at https://cipher-x402-mcp.vercel.app/mcp as the streamable-HTTP endpoint. When an MCPize user clicks "install for Claude Desktop" or copies the npx -y cipher-x402-mcp command, their client speaks MCP directly to my Vercel deployment. The 402 dance happens entirely between their wallet and my facilitator.

Exact MCPize listing path (the one-minute version)

MCPize's happy path assumes you want them to host everything. You do not want that. The path that keeps the marketplace at arm's length is:

1. Go to mcpize.com/new. Enter the display name and description.
2. Click Advanced Options — this is the escape hatch that hides the bring-your-own-endpoint flow.
3. In Your Server endpoint, paste the public streamable-HTTP URL of your MCP server. In my case https://cipher-x402-mcp.vercel.app/mcp.
4. Skip the GitHub App connection. MCPize offers to clone your repo, build it, and host it on their infra. Don't. You want the listing to point at your own deployment so payment goes through your own wallet logic.
5. Skip Stripe Connect. The UI will nudge you to connect a Stripe account so "your users can subscribe." Say no. Stripe Connect is how MCPize takes its 15%. With x402 pricing embedded in tool responses, you do not need it.
6. Optionally, connect a domain and upload an icon. Neither changes the billing path.
7. Publish. The listing shows up in their directory, searchable by tag, name, and tool capability.

That is the full ceremony. You have now exported discovery to MCPize while importing zero platform take.

Official MCP Registry listing (free, no take, still worth doing)

The Official MCP Registry at registry.modelcontextprotocol.io is the non-commercial directory run by the MCP working group. It is a thin JSON index, not a marketplace; it does not offer billing, does not run your code, and does not take a cut. You should list there in addition to MCPize because most first-party client integrations (Claude Desktop, Cursor, Cline) read it directly.

The listing is a single server.json in your repo. Mine is here. The important fields are name (must be io.github.<owner>/<repo>), websiteUrl, and the remotes array pointing at the streamable-HTTP endpoint. Push it to main, submit via the registry's publish endpoint (or via the mcp-publisher CLI), and the entry is live inside a few minutes. You can verify your listing with:

curl 'https://registry.modelcontextprotocol.io/v0/servers?search=cipher'

Zero platform take on the registry side. Pure discovery.

Side-by-side: MCPize paid-tier vs self-hosted x402

Numbers make the comparison honest.

The Stripe route is genuinely better for fiat subscribers who expect normal consumer billing. The x402 route is an order of magnitude better for machine-to-machine micropayments, which is the actual use case for an MCP server being called by an agent — agents do not file chargebacks, and the price points that make per-call pricing interesting ($0.005 per breach check, $0.01 per wallet scan) are below Stripe's cost floor by a factor of roughly fifty.

For the cipher-x402-mcp use case — eight tools priced $0.005 to $0.25, most calls from automated agents — the self-hosted route is not a clever hack. It is the only route that works. Stripe would eat the entire revenue at those price points.

Why "forward-only relay" is the load-bearing phrase

I keep using the phrase forward-only relay. It matters for two reasons.

First, legal clarity. In Canadian terms (see my prior post on NI 31-103) you do not want to be the party custodying other people's stablecoins. Forward-only means at no point does a payment sit in a balance you control before reaching the end merchant. The signed EIP-3009 permit is scoped to the exact transfer, with an exact nonce, to an exact recipient. The relay has no key that can redirect it.

Second, operational simplicity. A forward-only relay is stateless. It holds no database of accounts, no session store, no webhook queue. Deployment is a single Vercel function. Monitoring is HTTP logs. This is the exact opposite of a marketplace platform — and it is why the marketplace's billing surface adds no value when you already have this piece.

What you lose by bypassing MCPize billing

Being honest here: the bypass route costs you things that are worth real money for some businesses.

• Receipts and invoices. x402 produces on-chain transfers, not line-item invoices with your company address on them. Enterprise buyers who need to expense a call to their finance team may not accept a Basescan link.
• Refunds. x402 transfers are final. If a buggy tool burns an agent's $0.25, the agent has no platform-mediated refund path.
• Subscription bundles. Pay-per-call is great for agents, bad for humans who want "unlimited access for $20/mo." MCPize handles the bundle SKU natively.
• Currency. A buyer without a funded Base wallet cannot pay you. That is most humans, today. It is almost no agents.
• Fiat settlement. Your revenue lands as USDC on Base. Converting that to CAD or USD takes a CEX hop and any applicable capital-gains treatment in your jurisdiction.

If your buyers are humans expecting consumer billing, take the 15% and use MCPize's Stripe rails. If your buyers are agents paying per call in the $0.001 – $0.25 range, route payment yourself.

The whole picture

I ship a tiny stack that composes four things:

• cipher-starter — the free 150-page solo-dev playbook (MIT).
• cipher-x402 — the paid content surface, x402-gated at $0.25 USDC per chapter.
• cipher-x402-mcp — the MCP server that exposes seven paid tools as callable functions to any MCP-aware client.
• Listings on MCPize and the Official MCP Registry for discovery.

Total monthly infrastructure bill: $0. (Vercel Hobby + GitHub Pages + Base gas paid by callers.) Platform take on paid calls: 0%. Settlement time: ~2 seconds on Base. This is the shape a single-developer x402 product looks like when you route around every fee layer that does not add value to an agent-first use case.

If you are building an MCP server and you already have x402 gating working, take thirty seconds, open MCPize, skip the Stripe Connect step, and paste your existing endpoint URL. You will keep every dollar your tools earn.

Tools, tests, and the full ruleset are on GitHub. Prior posts on the wallet-audit action, the Canadian compliance map, and the 3-hour x402 deploy cover the adjacent pieces.