Definition
A paid MCP tool is a tool on an MCP server that a caller must pay to use. Because the x402 adapter prices per HTTP route rather than per individual tool, a paid tool is really a tool served behind a priced route: a call returns a 402, the caller settles in USDC on Base, and the tool runs. Discovery and free tools stay on unpriced routes.
In short, a paid MCP tool is a normal MCP tool with a paywall in front of it. The tool itself, an action an agent can call on an MCP server, is unchanged; what makes it paid is that the route serving it is gated, so the call settles a payment before the tool executes. That lets a server charge for the capabilities worth charging for, while keeping the rest free, and it is how an MCP server turns useful tools into revenue.
How a tool becomes paid
A tool becomes paid when the route serving it is gated with x402. On an MCP server using the Streamable HTTP transport, you front the route with the x402 adapter and set a price for it. After that, a call to that route returns an HTTP 402 quoting the price unless it carries a valid payment, and the adapter verifies payment before the MCP server runs the tool. The tool's own code does not change; the paywall sits in front.
So making a tool paid is a matter of gating its route, not modifying the tool. This separation, the tool does its job, the gate handles payment, is what keeps paid MCP tools simple to reason about. You decide which routes are priced and at what amount, and the adapter enforces it. The mechanics of arranging this across a server are covered in mcp-paid-tools; the definition to hold onto is that paid means the serving route is gated.
The route-level reality
The most important nuance is that x402 prices per route, not per individual tool. The adapter sits in front of an HTTP route and gates whatever that route serves; it does not inspect which MCP tool a call names. So if all your tools share one route, they all share one price. A paid MCP tool is therefore, precisely, a tool served behind a priced route, and per-tool pricing is really per-route pricing.
This matters when you want different tools at different prices. You cannot set a price field on each tool within one route; instead you arrange tools across routes, grouping them by price, and price each route. A cheap tool and an expensive tool live on separate routes with separate prices; free tools live on ungated routes. Thinking in routes rather than tools is the practical reality of paid MCP tools, and missing it leads to confusion about why per-tool prices do not appear as a per-tool setting. The route is the unit of pricing.
What a caller experiences
From the calling side, a paid MCP tool behaves predictably. The caller, often an AI agent, invokes the tool, and instead of a result it gets back a 402 with the price, the accepted token, and the pay-to details. Its x402 client settles the amount in USDC from the agent's wallet, within the wallet's spend limit, and retries the call. This time the adapter verifies the payment and the tool runs, returning its result.
To the agent, this is close to calling any tool, with payment handled by its client underneath. There is no signup and no account; the agent pays per call on first contact and proceeds. If the agent cannot afford the call or its spend limit refuses it, the payment does not go through and the tool does not run, which is the intended bound. So the caller experiences a paid MCP tool as a tool that costs a small, known amount to use, paid automatically by its wallet, which is exactly the frictionless per-call model the agent economy needs.
Free versus paid tools
A well-designed MCP server mixes free and paid tools, and the split is deliberate. Discovery stays free: the step where a caller lists the server's tools belongs on an unpriced route, so an agent can see what is offered before paying for anything. Gating discovery would defeat the model, since a caller cannot choose to pay for a tool it cannot see. Low-value or exploratory tools also usually stay free, because the friction of payment would exceed their worth.
Paid tools are the ones that cost you to run or deliver real value, a tool that calls an expensive upstream service, runs heavy computation, or returns proprietary data. The art is deciding which tools earn a price and which stay open, and arranging them across routes accordingly. So a paid MCP tool exists within a server that also offers free ones, and the distinction between them is a routing-and-pricing decision, with discovery always free. This free-and-paid mix is what makes a paid MCP server usable rather than a closed box.
Why charge for a tool
You charge for an MCP tool when it provides something worth paying for and you want machine callers to pay per use with no signup. A tool backed by an expensive data source, real compute, or a specialized capability is worth a price that covers its cost plus a margin, and gating it turns usage directly into revenue from any capable agent, including ones you have never met.
The alternative monetization models, subscriptions or accounts, do not serve arbitrary machine callers, who cannot sign up, so for an MCP server meant to be reached and paid by agents, per-call paid tools are the model that fits. Charging per tool call also aligns cost with use: a caller pays for exactly the tools it invokes, which is fair to occasional users and scales with heavy ones. So a paid MCP tool is the unit of monetization for an agent-facing MCP server, and choosing which tools to charge for is choosing how the server earns.
How a paid tool is priced
Setting the price of a paid MCP tool follows from its cost and value. Start from what the tool costs you to run, the upstream API fees, compute, or data it consumes per call, and price the route above that with a margin, so each call is profitable. A tool that costs you a cent to serve might be priced at two or three cents; one that returns expensive proprietary data might command more.
Then adjust on real usage. If a tool sells well, the price may have room to rise; if it barely sells, the price may be too high or the tool too marginal to gate. Because pricing is per route, you tune the route's price and watch the per-route revenue, which is the signal that tells you whether a tool is priced right. Keeping that loop, price from cost, adjust on data, is how a paid MCP tool earns rather than just exists, and it is the difference between a server that grows and one that stalls.
Related terms
A paid MCP tool connects to several concepts. An MCP server is what hosts the tool. The x402 protocol is how the tool charges. Route-level pricing is the reality behind per-tool pricing. A free discovery route is what keeps callers able to choose. And monetizing an MCP server is the broader activity a paid tool is part of.
Understanding the paid MCP tool is understanding the unit of MCP monetization. For the server that hosts it, see what-is-an-mcp-server; for how to arrange and price tools, see mcp-paid-tools. Pricing is on the pricing page.