Who this is for

This guide is for anyone who has built, or is building, an MCP server with valuable tools and wants it to earn rather than give its capabilities away. Maybe your server wraps an expensive data source, runs real computation, or exposes a specialized capability, and agents are using it for free while you absorb the cost. The use case is turning that server into a paid service that machine callers pay per use, with no signup, so usage becomes revenue.

It is a guide rather than a single how-to, because monetizing an MCP server spans a few stages, deciding what to charge for, building the paywall, and operating it, each of which has its own depth. This page connects those stages into one journey and points to the detailed pages for each, so you can see the whole path and then go deep where you need to. If your goal is a paid MCP server, this is the map; the linked pages are the terrain.

The three stages

Monetizing an MCP server breaks into three stages. First, decide what to charge for: which tools earn a price and which stay free, and at what amounts. Second, build the paywall: serve the server over the Streamable HTTP transport and gate its routes with the x402 adapter so calls settle in USDC per use. Third, operate it: confirm payments, watch revenue, and tune prices over time.

These stages are sequential but the third is ongoing. You decide and build once to launch, then operate continuously as the server earns. Skipping the first stage leads to gating the wrong things or charging poorly; skipping the third leaves money on the table from prices you never revisit. So treat all three as part of the use case, not just the build. The rest of this guide walks each stage and links the page that covers it in depth.

Stage 1: Decide what to charge for

The first stage is judgment, not code. Decide which tools are worth charging for, the ones backed by expensive data, heavy compute, or proprietary capability, and which should stay free, namely discovery and low-value or exploratory tools. A caller needs to see what your server offers before paying, so the tool-listing step stays free, and trivial tools are rarely worth the friction of a charge.

Because x402 prices per route rather than per individual tool, deciding what to charge for also means arranging tools across routes by price tier, so each route's price fits the tools behind it. Set each price from the underlying cost plus a margin. This stage shapes the whole monetization, charge for value, keep discovery open, group by price, and getting it right makes the rest work. The detail of which tools to charge for and how route-level pricing maps onto them is in the paid-tools material, and the strategy in best-mcp-server-payment-solution.

Stage 2: Build the paywall

The second stage is the build, and it is short once your transport is right. Serve the MCP server over the Streamable HTTP transport, because the x402 adapter gates an HTTP route and stdio has none. Then register the adapter, createX402Plugin (Fastify) or createX402Middleware (Express), in front of the route with your per-route pricing, so an unpaid call gets a 402 and a paid one settles in USDC on Base before the tool runs. Leave a free discovery route so callers can list your tools.

That is the paywall: transport, gate, free discovery. Your tools do not change; the adapter sits in front and enforces payment. Test it on Base Sepolia with a sk_test_ key, confirm an unpaid call gets a 402 and a paid one runs, then swap to a sk_live_ key for mainnet. The full step-by-step build, including the MCP server itself, is in how-to-build-a-paid-mcp-server. With this stage done, your server earns per call.

Stage 3: Operate it

The third stage is operating the paid server, which is ongoing. Confirm payments by listening for the payment.received event and verifying each, building a durable record of what your server earns. Watch that record per route to see which tools earn, how much, and how often, which is the signal for whether your prices are right. And tune: raise a price with room, lower or drop a tool that barely sells, add a route for a new premium tool.

This operating loop, confirm, observe, adjust, is what turns a launched paywall into a growing revenue source. It also keeps the server healthy: monitoring catches anomalies, and per-route revenue tells you where demand is. Because the server is stateless and per-call, scaling it is straightforward, add instances behind a load balancer as traffic grows. Operating well is the difference between a paid server that stalls at its launch prices and one that improves as you learn how callers use it, which is why this stage is part of the use case, not an afterthought.

What good looks like

A well-monetized MCP server has a few hallmarks. Discovery is free, so any capable agent can evaluate it and decide to pay. The valuable tools are priced for their cost and value, and the trivial ones are free. Payments settle per call in USDC with no signup, so the addressable market is every agent that can pay. Each paid call is confirmed durably via webhooks, and per-route revenue is visible, so pricing is data-driven. And the server is bounded operationally, stateless, scalable, with prices that get tuned rather than set once.

That is the target state the three stages build toward: a server that earns from machine callers automatically, priced well, confirmed reliably, and improving over time. If your paid server has those properties, monetization is working; if it is missing some, the stages point at what to add. Use this as the checklist for a finished monetization, not just a launched one.

What callers experience

It helps to design with the caller's experience in mind, because a paid MCP server only earns if callers happily pay. To a calling agent, your server should feel almost like a free one: it lists the tools for free, the agent picks the one it needs, and when it calls a paid tool, its x402 client settles the small payment automatically and the result comes back. There is no signup, no account, no interruption, just a call that costs a known, small amount.

That frictionlessness is what makes per-call monetization work at agent scale: the agent pays without a human in the loop and proceeds, so a fair price is simply paid rather than negotiated. So as you set prices and arrange routes, keep the caller's view in mind, clear free discovery, sensible prices, and smooth per-call payment, because a server that is easy and predictable to pay is one agents will keep calling, which is ultimately what turns monetization into sustained revenue.

Getting started

To get started, work the stages in order. Decide what to charge for and arrange tools across priced and free routes. Build the paywall by serving Streamable HTTP and gating with the adapter, testing on Base Sepolia. Then operate it, confirming payments and tuning prices. The deep pages are how-to-build-a-paid-mcp-server for the build and best-mcp-server-payment-solution for choosing your monetization approach. Pricing is on the pricing page.