The constraint that decides everything#
A Model Context Protocol tool call is a JSON-RPC message inside a session the client manages. The tool cannot set HTTP headers. It has no access to the transport; the client owns that.
x402 puts the payment in a header. So per-call x402 payment by the caller is not available over MCP, and no amount of design works around it. This is not a gap to be filled in a later version; it follows from where the two protocols sit.
What follows is that a paid MCP server charges at a different layer from an HTTP API, and conflating the two produces a surface that refuses calls with instructions nobody can follow.
The pattern that works#
A prepaid balance on the account behind the connection.
- The caller authenticates to your MCP server. In practice that is an API key or an OAuth login, since those are the two things an MCP client can actually present.
- That credential resolves to an account with a balance.
- Each tool call draws down the balance according to what the tool costs.
- When the balance runs out, calls are refused with an actionable message.
- The balance is topped up out of band, over HTTP, where x402 does work.
Step 5 is where x402 earns its place. The top-up is an ordinary HTTP request that can carry a payment header, so a buyer can fund an account with one settled payment and no sign-up. That gives you the property that mattered, which is a buyer who can start without an account, without requiring the impossible thing.
Note
Note what this costs: metering moves from per-call to per-connection. You are charging for a relationship rather than for a request, which is closer to API keys than to x402's usual shape. That is the honest trade and it is forced by the transport.
Getting the refusal right#
The failure that matters most is the one where a caller runs out of balance, because it is the one that happens to paying customers.
Three rules, all of which are learned by getting them wrong.
Do not repeat your HTTP wording. "Resend this request with an X-PAYMENT header" is correct on your HTTP surface and impossible on MCP. A refusal telling a client to do something it cannot do is a dead end that reads like instructions.
Put everything actionable in the message, not in structured error data. Measured in 2026, at least one major MCP client delivered the refusal message verbatim and dropped the structured data field entirely. A refusal whose useful half is in data is a refusal the reader never sees. If the top-up URL matters, it goes in the sentence.
Never hand a keyed caller a payable challenge. If a caller has an account and has run out, giving it an x402 challenge invites a client library to settle a wallet to solve a billing problem. Say the balance is empty and where to top it up.
What should be free?#
More than you think, and this is a design decision rather than generosity.
MCP requires a successful initialize before any other method. If you gate initialize, a conforming client cannot reach your tool list at all, which means it cannot discover what you offer. Gating discovery means nobody finds out what they would be paying for.
A reasonable split:
| Method | Free? | Why |
|---|---|---|
initialize | Usually | Gating it makes the server undiscoverable |
tools/list | Yes | The tool list is your menu |
| Cheap read tools | Often | Lets a caller evaluate quality |
| Expensive tools | No | This is the product |
The exception is deliberate gating for a different purpose. Some clients auto-detect "no authentication required" from a keyless initialize and then never attempt a login flow at all, so a server that wants to drive an OAuth connection may have to gate initialize specifically to make the sign-in appear. That is a real trade: you lose keyless discovery to gain a working auth flow.
How should tools be priced?#
By cost and by call, as with any endpoint, with one MCP-specific consideration.
A model calling tools does not see your prices unless you put them somewhere it reads. Tool descriptions are the only prose the model reliably gets, so if cost should influence which tool it picks, say so there. A tool whose description does not mention that it is the expensive one will be called as often as the cheap one.
Published price points for discrete tools in 2026 ran from roughly $0.001 to $0.05 per call. Pricing for agents covers the method.
Frequently asked questions#
Can I avoid accounts entirely on MCP?#
Not really. Something has to identify the connection to meter it. The nearest thing is a credential minted by a payment, so the buyer never fills in a form even though an account exists.
Should I use OAuth or API keys?#
Both, if you can. Keys suit developers configuring a server by hand; OAuth suits clients whose only auth control is a sign-in button, which includes several mainstream assistant connectors.
Does the same server work over HTTP and MCP?#
It can, and keeping one implementation behind two transports is the right structure. Just remember the refusals differ, because one caller controls headers and the other does not.
How do I handle a tool that is expensive and slow?#
Charge for it, and consider returning a cheap estimate tool alongside so a caller can decide before committing. A model that can ask what something will cost makes better choices than one that cannot.
What stops someone running up a bill?#
The balance. Prepaid metering means the worst case is that a caller spends what it has already funded, which is the same self-limiting property that makes x402 safer than a free tier.
Where to check this yourself#
The MCP documentation covers how Roundhouse exposes its index as tools, which methods are keyless, and how the balance behind a connection is metered. It is a working instance of the pattern above rather than a specification.