Skip to main content
LearnGlossaryPaid MCP tool
GLOSSARY

What is a paid MCP tool.

DEFINITION

A paid MCP tool is a tool exposed by an MCP server that returns HTTP 402 with a payment URL until the calling agent's wallet settles. After settlement, the same call returns the actual result. The tool is otherwise indistinguishable from a free MCP tool in how it is advertised, discovered, and invoked.

WHY IT MATTERS

Monetization that does not need a sales team.

Without paid MCP tools, a developer who builds something useful for agents has two unattractive options: keep it free and hope for adoption, or set up a SaaS company around it (signup flows, billing portals, API key issuance, dunning, support). Both routes ignore the actual user - an autonomous agent that just wants to call the tool.

Paid MCP tools collapse the onboarding step to zero. The first time an agent calls the tool, the 402 acts as a price tag and a checkout in one. If the agent's wallet has budget, the call goes through; if not, the call stops cleanly with a useful error. There is no signup, no API key, no shared secret to leak. The tool is paid because the protocol made it paid, not because a sales process made it paid.

HOW IT WORKS

Call, 402, settle, retry, result.

  1. Call. The agent invokes the tool through the normal MCP transport with structured arguments.
  2. 402. The server checks for a valid prior payment for this caller and this tool. If none exists, it returns HTTP 402 with a payment URL and the quoted price for this call.
  3. Policy check. The agent's wallet runtime checks the quoted price against the agent's spend policy. Within budget and counterparty rules, it proceeds; otherwise the call fails with a policy error.
  4. Settle. The wallet pays the URL in USDC. The wallet provider confirms the payment to the server, typically via a signed webhook.
  5. Retry and result. Once the server has marked the caller paid, the agent re-invokes the tool; the server runs it and returns the actual result.

The agent's planner does not need to understand any of this. From its perspective, the call took slightly longer and the agent's audit log gained one transaction line. Everything else is the runtime's job.

EXAMPLES

Three paid-tool shapes.

EXAMPLE 1

A premium market-data tool

An MCP server exposes free tools (list_tickers, get_quote_delayed) and one paid tool: get_quote_realtime. The free tools have a regular 200 response. The paid tool returns 402 with a payment URL on first call. Once the agent's wallet settles $0.005, the call retries and returns the live quote. Same server, same protocol; only the one tool is gated.

EXAMPLE 2

A pay-per-page web-crawler tool

A crawl_page tool charges $0.001 per page fetched and parsed. Every call is paid - there is no free tier. The server stays cheap to operate because every invocation funds itself. The agent's spend policy caps how many pages a day it can crawl, which is the natural answer to runaway loops.

EXAMPLE 3

A subscription-style tool with a free trial allowance

A 'first 50 calls per month free' tool returns 200 for the first 50 calls in a billing window and 402 for the 51st onward. The agent's wallet pays a $5 USDC top-up to cover the next 1,000 calls. From the agent's perspective, the 402 is invisible most of the month; from the provider's perspective, monetization is automatic.

FAQ

Three common questions.

Does the agent always pay the same price for the same tool?

Not necessarily. The 402 response includes the price for this specific call, so the server can vary it - by argument size, by time of day, by tier, by per-customer contract, by surge. The agent's wallet checks the quoted price against the agent's spend policy before settling. If the price is over the limit, the call fails with a policy error rather than a payment. The protocol makes dynamic pricing safe because every price is explicit.

What happens if the tool fails after the agent has paid?

The same thing that happens with any paid API: the server is responsible for either delivering the result or refunding the payment, per its terms. Well-designed paid MCP tools settle payment only after the work succeeds (the 402 includes a hold or escrow URL) or refund on failure. The protocol does not enforce this; it is a quality-of-implementation concern for each tool provider, the same way SLA enforcement works for any paid API.

Can an agent refuse to pay and just call the free tools on the same server?

Yes, and that is the intended behavior. The free tools return 200 directly; only the gated tools return 402. The agent's planner can choose: skip the paid tool, find another way to accomplish the task, or settle and proceed. This is how marketplace dynamics work - cheaper, lower-quality free tools coexist with paid premium tools, and the agent chooses based on the value of the answer.
Last reviewed: 2026-05-15. Published under CC BY 4.0.

Charge per tool call.

Return 402, name your price, accept USDC. Free to start.