What a paid tool is

An MCP paid tool is a tool a caller pays to use, with the payment settled in USDC on Base per call. The tool itself is an ordinary MCP tool; what makes it paid is that the route it is served on is gated by the @blockchain0x/x402 adapter, so a call to it returns a 402 until payment is settled. From the caller's side, using a paid tool is calling it, getting asked to pay, paying, and getting the result.

This page is about the tool level: which tools to charge for and how charging maps onto MCP's structure. For the server architecture see mcp-payment-server; for the monetization strategy see mcp-server-monetization. The payment API product page is the reference. The one thing to understand first is how pricing attaches to tools, because it is not where most people expect.

Pricing is per route, not per tool

Here is the fact that shapes everything about paid tools: the x402 adapter prices per HTTP route, not per individual MCP tool. The adapter sits in front of a route and gates whatever that route serves; it does not inspect which MCP tool a tools/call names. So if all your tools are served on one /mcp route, they all share one price, and a single pricing entry covers every call to that route.

This surprises people who imagine setting a different price on each tool in one server. You cannot, not within a single route. What you can do is decide pricing at the route level and arrange your tools across routes to get the pricing you want. Once you think in routes rather than tools, paid tools become straightforward: the route is the unit of pricing, and a tool's price is the price of the route it lives on.

Map tools to routes

Because pricing is per route, charging different amounts for different tools means putting them on different routes, each with its own pricing entry.

await app.register(createX402Plugin, {
  sdk,
  defaultNetwork: "testnet",
  pricing: {
    "POST /mcp/search":  { amountUsdc: "0.01", payToAddress: process.env.B0X_PAYTO_ADDRESS!, paymentRequestId: "pr_search" },
    "POST /mcp/analyze": { amountUsdc: "0.20", payToAddress: process.env.B0X_PAYTO_ADDRESS!, paymentRequestId: "pr_analyze" },
    // POST /mcp/free is omitted, so it is not gated
  },
});

Here a cheap search tool and an expensive analyze tool live on separate routes at separate prices, and a free tool sits on an ungated route. Each route can serve one tool or a tier of similarly priced tools; group tools by price, give each group a route, and the route prices them. This is the practical shape of per-tool pricing in MCP: route mapping, not a per-tool field.

Resist the urge to split every tool onto its own route by reflex, though, because each route is a thing to name, price, and maintain. If five tools are all worth about the same, one route at one price serves them cleanly and keeps your pricing map small. Split only where prices genuinely differ, so the number of routes tracks the number of price tiers rather than the number of tools. That keeps the mapping honest and the configuration readable as the server grows.

Which tools to charge for

With the mechanism clear, the judgment is which tools earn a price. Charge for tools that cost you real money to run or deliver real value: a tool that calls an expensive upstream API, runs heavy compute, or returns proprietary data is worth a price that covers its cost plus a margin. A trivial tool that formats a string or echoes input is not worth gating; the friction of payment would exceed its value.

A useful default is to keep cheap, low-value, and exploratory tools free and price the tools that do the expensive or valuable work. That mirrors how a caller experiences the server: free tools let it get started and understand the server, and paid tools are where it draws on something that costs you to provide. Set each paid route's price from the underlying cost of its tools, then adjust on real usage. The broader pricing strategy lives in mcp-server-monetization; the tool-level point is to price by cost and value, and to leave the cheap stuff free.

Keep discovery free

Whatever you charge for, keep discovery free. The tools/list step, where a caller learns which tools exist and what they do, belongs on an unpriced route, so a caller (often an agent) can see the menu before paying for anything. Gating discovery defeats the model: a caller cannot decide a tool is worth paying for if it cannot first see that the tool exists and what it does.

So the structure is a free discovery surface plus priced tool routes. A machine caller lists the tools for free, reads their descriptions, decides which paid tool it needs, and calls that route, paying for it. Keeping the menu open and pricing the dishes is what lets an agent choose your server in the first place, and it costs you nothing because listing tools is cheap. Treat free discovery as a requirement, not a courtesy.

Compatibility

Paid tools work wherever the MCP server speaks HTTP and routes can be gated.

When this fits

Paid tools fit when a server exposes tools worth charging for to callers who can pay per use, especially other agents. The route-mapping approach fits naturally when tools fall into a few price tiers (free, cheap, premium), since you give each tier a route. It fits a server with a mix of free and valuable tools particularly well, because the same server can do both.

It fits less well when you genuinely need a distinct price for every one of many tools, which means many routes to manage, or when the server is internal with no external caller to charge. For the common case of a few tiers of tools sold to machine callers, route-mapped pricing is the model that matches MCP's structure.

Pricing

Charging for tools is free to set up; you pay the wallet platform fee per agent on the pricing page: Free is $0 per agent per month at a 5% transaction fee, Pro is $9 at 2%, Business is $29 at 1%. The fee applies to the server's agent profile that receives the USDC and scales with what the tools earn rather than a flat seat.

What to ship today

Group your tools by price, put each group on its own route, and add a pricing entry per priced route while leaving free tools and tools/list ungated. Confirm a paid route returns a 402 then runs on Base Sepolia and a free route does not. For the server architecture see mcp-payment-server; for strategy see mcp-server-monetization. Pricing is on the pricing page.