You wrote an MCP server, agents call it, and every call costs you money. The obvious next step is to charge for it, and that is where most people discover the protocol offers no help at all.

Here is the short version, by situation.

• Remote HTTP server, autonomous agent callers, dollar pricing. Use x402. Cloudflare, Vercel and Coinbase all ship a working wrapper.
• Human at the keyboard in Claude or ChatGPT. Use OAuth plus your own subscription. Stripe documents the checkout flow for exactly this.
• Hundreds of small calls in one session. Look at MPP, or sell credits with Nevermined.
• You want distribution more than control. Publish on a marketplace that bills for you, such as Apify.
• You cannot get a merchant account, or you are an agent with no company behind you. Bitcoin routes are the only ones that work: L402 or Hypawave.
• Your tool call is expensive and one-shot (an inference job, a scrape, a report). Gate the handler on settlement rather than metering usage.

Everything below is sourced to official documentation, and it is a companion to our wider survey of payment platforms for autonomous agents. See methodology and sources for how each claim was checked.

MCP has no payment layer, and that is the whole problem

The 2026-07-28 specification is the largest revision since launch. It made the protocol core stateless, dropped the initialize handshake, added multi round-trip requests, cacheable list results, header-based routing, a formal extensions framework, and hardened authorization with RFC 9207 issuer validation and Client ID Metadata Documents. It contains nothing about money.

That is not an oversight anyone is ignoring. Payment support has been proposed three times. On 23 December 2025 a contributor filed SEP-2007, a Standards Track proposal to let servers charge for tool invocations, with a protocol-agnostic framework and x402 v2 as the first supported method. Its design was sensible: servers declare payment capability, clients see prices in tools/list, a paid tool returns error code -32402, the client retries with a signed payment authorization. Two companion issues were filed the same day. All three are closed, and the pull request was closed unmerged on 24 June 2026.

The pressure has not gone away. On 11 August 2026 someone opened RFC #3229, asking for native token metering, session budgets and payment tracking, and framing it as a safety problem rather than a commerce one. It opens with agents running up "massive, unexpected API bills" because nothing in the protocol imposes a spending guardrail. That issue is open at the time of writing with no maintainer response.

So the practical position in August 2026 is simple. Every paid MCP server in production is running a layer that the protocol does not define, and nobody has to be interoperable with anybody.

Your transport decides half of your options

The spec defines exactly two standard transports: stdio, meaning newline-delimited JSON-RPC over the standard streams of a client-launched subprocess, and Streamable HTTP, where each message is an HTTP POST to a single endpoint.

This matters more than it sounds. Every popular payment scheme for MCP is built on the HTTP 402 status code. x402, MPP and L402 all work by answering an unpaid request with 402 plus machine-readable payment requirements, then honoring a retry that carries proof. A stdio server has no HTTP layer and therefore no status codes, so none of those schemes apply to it.

If your server runs locally, payment has to happen inside the tool call. The tool returns an invoice or a payment challenge in its result, the agent pays out of band, and a later call presents proof. That is more work than importing a wrapper, but it has one advantage worth noting: it survives any transport, including stdio, custom sockets and whatever the extensions framework produces next.

Four problems, not one

"Charging for tool calls" bundles four separate jobs, and most tooling only solves some of them.

1. Identify the caller. MCP's authorization spec covers this well with OAuth 2.1, and the July revision tightened it further. This is the one piece the protocol genuinely gives you.
2. Price a unit. A call is rarely the unit anyone values. Tokens consumed, rows returned, a job completed, a seat per month: pick the one your buyer would recognise on an invoice.
3. Collect the money. Rails, custody, refunds, chargebacks, and whether the payer is a person with a card or a process with a wallet.
4. Gate the handler. Verify the payment applies to this call, exactly once, and refuse to run otherwise.

Note that 4 is where correctness bugs live. Retries, at-least-once webhooks and agents that call the same tool twice in a loop will all bill someone twice unless you enforce idempotency yourself.

The options

Your own auth plus your own billing

The conservative choice. Put OAuth in front of your remote server, look up the customer's plan on each call, meter usage, and bill on Stripe like any SaaS product.

Stripe documents this path directly for MCP builders on its Monetize your MCP app page, with two options. Redirect sends the customer to a prebuilt checkout page in a new tab, is publicly available, and supports subscriptions, promo codes, tax and saved payment methods. Instant Checkout keeps the customer inside ChatGPT, but it is in OpenAI private beta and, per Stripe's own comparison table, does not support subscriptions, 3DS or saved payment methods.

One point of confusion worth clearing up, because it wastes a lot of people's time: Stripe's MCP server at mcp.stripe.com is a server that lets your agent call the Stripe API. It is not a way to charge for your own MCP server. Those are different products and the docs link across to each other.

Where it falls short. It requires a legal entity, a bank account and KYC, so an autonomous agent cannot use it and neither can a developer in a country Stripe does not serve. It also assumes a human at checkout, which is the wrong assumption for a server whose callers are other machines.

x402, per call

The default for remote servers with agent callers, and the best supported option by a distance.

Cloudflare's Agents SDK documents charging for MCP tools with a paidTool drop-in replacement for tool, so free and paid tools live in the same server. You configure a network (base or base-sepolia), a recipient wallet address, and a facilitator, which defaults to https://x402.org/facilitator:

const X402_CONFIG: X402Config = {
	network: "base",
	recipient: "0xYourWalletAddress",
	facilitator: { url: "https://x402.org/facilitator" },
};

Prices are plain USD decimals, so 0.01 is one cent. When a client calls a paid tool without payment, the server returns 402 with payment requirements, the client pays and retries with proof, and the result comes back. Cloudflare notes that servers can offload verification and settlement to a facilitator, so your worker never needs blockchain connectivity.

Vercel published x402-mcp in September 2025 covering the same ground for the AI SDK, with createPaidMcpHandler on the server and withPayment(client, { account }) on the consumer. Coinbase documents the buyer side with a CDP-managed wallet, so no private keys are handled manually. MCPay wraps the whole thing as a hosted service with a registry listing, and supports both wallet-based x402 and plain API keys for clients that cannot sign.

Where it falls short. Most implementations settle in USDC on Base, so both sides need an EVM wallet and the buyer needs funds on the right chain before the first call. Onboarding friction on the agent side is the recurring complaint in the ecosystem, including from server operators who otherwise like the protocol. And it prices per call, which is the wrong shape for chatty tools.

MPP, per session

Cloudflare's agentic payments overview also supports the Machine Payments Protocol, which adds WWW-Authenticate: Payment and Authorization: Payment headers to 402 responses and covers one-time, usage-based and recurring payments across stablecoins, cards through Stripe and custom methods. It is backwards compatible with x402, so MPP clients can consume existing x402 services without modification.

Use it when an agent makes many calls in one working session and you would rather settle once at the end than mint a payment per call.

Where it falls short. It is young. MPP shipped in March 2026, and its card path inherits Stripe's entity requirements.

Nevermined, credits and plans

Nevermined takes a different angle: instead of a payment per call, it puts a paywall in front of your MCP handlers that "acts as a gatekeeper, intercepting every incoming request to a tool, resource, or prompt." You wrap handlers with withPaywall, or call payments.mcp.start() with a planId, and after a successful execution the paywall deducts credits. Credits can be fixed per call, or dynamic based on the arguments or the size of the response. Settlement runs through ERC-4337 account abstraction for crypto plans, or cards through Stripe and Braintree for fiat plans.

Use it when the unit you want to sell is a plan or a balance rather than a transaction, and you want the metering handled for you.

Where it falls short. You add a vendor to the authorization path of every single tool call, and you need a Nevermined account, API key and registered plan before anything works.

A marketplace that bills for you

If distribution matters more than control, let someone else own the payment relationship. Apify hosts MCP servers, publishes them across its ecosystem and partner platforms, and bills on a pay-per-event model where you add Actor.charge('eventName', count=N) to your code and define event prices in the console. Its monetization docs state the developer receives 80% of the revenue charged, with monthly payouts and no cost to publish or host.

Where it falls short. You take the platform's rate, their payout schedule and their audience, and your server is only paid inside their ecosystem.

L402, Lightning-native

The Lightning HTTP 402 scheme from Lightning Labs, which got a dedicated home at l402.tech in July 2026. A server answers with 402 plus a macaroon and a Lightning invoice, the agent pays in sats and retries with the preimage as proof, and the macaroon is reusable afterwards, so an agent pays once per endpoint and caches the credential. The site describes it as built for machine-to-machine interaction with "no accounts, no intermediaries."

Where it falls short. The seller needs a Lightning node, the ecosystem is a fraction of x402's, and the credential proves payment rather than delivery. Nothing in L402 binds the payment to what the server actually returns.

Hypawave, settlement-gated execution

Ours, so treat the rest of this section with the appropriate suspicion, and read the limitations at the end.

Hypawave sells actions rather than access. You create an offer with an execution_webhook, the buyer pays your Lightning address directly, and on settlement Hypawave POSTs you {payment_intent_id, offer_id, payment_hash, preimage, locked_amount_sats, payer_pubkey, settled_at}. The preimage is the useful part: the buyer's wallet revealed it to them when the payment settled, and the webhook delivered the same value to you, which makes it a shared secret established by the payment itself. Your tool call then verifies SHA-256(preimage) == payment_hash and runs the job on your own infrastructure.

The seller side needs no account, no API key and no KYC. A seller is a secp256k1 keypair, the identity is created on the first authenticated request, and principal never touches Hypawave. Our own MCP server exposes this as four tool calls, and it runs over stdio, which is the point made earlier about local servers: because payment lives inside the tool call rather than in an HTTP status code, the transport does not constrain it.

Where it falls short, honestly:

• Sats, not dollars. Price a call at 300 sats and its dollar value moves with Bitcoin.
• The buyer needs a preimage-returning wallet. Wallet of Satoshi and Phoenix mobile will pay an invoice and never expose the preimage, so they cannot unlock anything.
• The fee is charged upfront, as unit_price × max_payments × fee% when the offer activates, because a platform outside the payment path has no moment at which to deduct a cut. Better than a percentage if you sell steadily, worse if you are testing.
• One implementation, not a standard. x402 sits under the Linux Foundation with independent implementations. We are a single protocol operator.
• A small ecosystem. Far more agents speak x402 than speak this.

Side by side

Approach	Unit billed	Seller needs	Works on stdio	Legal entity or KYC
OAuth plus Stripe	Subscription or metered	Stripe account, entity	Yes	Yes
x402	Per call	EVM wallet address	No	No
MPP	Session or recurring	Wallet, or Stripe for cards	No	Cards only
Nevermined	Credits against a plan	Account, API key, plan	Yes	Fiat plans only
Apify	Per event	Apify account	Hosted only	Payout details
L402	Per endpoint, cached	Lightning node	No	No
Hypawave	Per settled action	A keypair and a Lightning address	Yes	No

The distribution catch nobody mentions

Where your paid server can live is a separate question from how it collects, and the answer is narrower than most people assume.

Claude's connectors directory lists over 950 MCP servers. Charging for a listed connector is fine, and commercial connectors are already there. What is not fine is a connector that moves money for the user. Anthropic's Software Directory Policy, dated 15 April 2026, lists Unsupported Use Cases under the line "Unless otherwise expressly permitted by us in writing, we do not allow Software with certain capabilities into our Directories," and one of those capabilities is "Software that transfers money, cryptocurrency, or other financial assets, or executes financial transactions on behalf of users."

Read that carefully, because the distinction is the one that matters for this article. A server that sells its own output and takes payment for it is a merchant. A server that spends the user's balance on their behalf, which is what a payment-capable MCP server is, falls in the excluded category. That includes ours. A local stdio install via npx is the route for anything in that class, and it is the route we use.

ChatGPT is more permissive but less finished. OpenAI's Apps SDK monetization guidance says "the recommended and generally available approach is to use external checkout," meaning you send the user to your own domain. The in-chat payment sheet exists but is a private beta limited to select marketplaces, and approvals are currently limited to physical goods.

The upshot: if your buyers are humans in a chat client, plan on sending them to your own checkout. If your buyers are agents, the client directories are not your distribution channel anyway, and a registry listing or a public offer directory is.

Charging for one tool call, end to end

Concretely, the shape we recommend for an expensive one-shot tool, using our own rails. This is Recipe 6 in the operating manual, and it is the same pattern behind our live compute demo.

Once, at setup. Create an offer with execution_webhook pointed at your HTTPS endpoint. No files needed if you are selling an action. Through the MCP server that is a single call:

create_offer {
  amount: 300, pricing_type: "sats",
  description: "One enrichment job, up to 1000 rows",
  payment_destination: "you@getalby.com",
  max_payments: 100,
  execution_webhook: "https://your-api.example.com/hypawave",
  is_public: true, title: "Company enrichment",
  category: "compute", output_type: "json",
  pay_activation_fee: true
}

Per sale. The buyer pays your Lightning address directly and confirms with the preimage. Hypawave POSTs your webhook. Then:

1. Verify the delivery cryptographically. SHA-256(hex-decoded preimage) == payment_hash, and the payload references an offer you own. Webhook POSTs carry no HMAC and no shared secret, so this check is the authentication, not a formality.
2. Store payment_intent_id → preimage with a unique constraint on payment_intent_id. That constraint is how you enforce one payment, one job.
3. Your paid MCP tool takes {payment_intent_id, preimage} as arguments, does a constant-time compare against the stored value, runs the job, and returns the result.
4. Reconcile missed deliveries. Webhook delivery is fire and forget with a 5-second timeout and no retry, so poll GET /api/offers/list-payments for your settled intents rather than assuming the POST arrived.

Two failure modes to design for. Deliveries can be missed, which is why step 4 exists. And an agent in a retry loop will call your tool repeatedly with the same credential, which is fine and correct here: the preimage buys one job, and every call after the first should return the stored result rather than running again.

How to choose

Work down the list and stop at the first line that matches.

1. Your callers are humans in a chat client. OAuth plus your own subscription, with external checkout.
2. You cannot get a merchant account, either because you are an agent or because card processors do not serve you. L402 or Hypawave.
3. One tool call does expensive work and delivery is the risk. Gate the handler on settlement, which is the pattern above.
4. Many small calls inside one session. MPP, or Nevermined credits.
5. You want distribution and will trade margin for it. Apify or a comparable marketplace.
6. Anything else, meaning a remote server with agent callers and dollar pricing. x402.

If none of them fits cleanly, default to x402 and revisit when the protocol picks a standard. Given that three proposals have already been closed, do not build a roadmap around that happening soon.

Methodology and sources

Research date. Every claim here was verified against primary sources on 13 August 2026. The MCP specification revision discussed shipped on 28 July 2026, sixteen days before publication, and the payments RFC cited was opened two days before publication. Treat anything in this article older than a quarter as needing a recheck.

What counts as a source. Official documentation, specifications, first-party announcements and the MCP repository's own issues and pull requests, linked inline at the point of use. We read the GitHub API directly for the status of every proposal cited rather than trusting summaries of it, which is how we caught that SEP-2007 is closed rather than pending, a detail several secondary write-ups get wrong. Competitor marketing pages and news aggregators were excluded when making factual claims about competitors.

Known uncertainties. We could not verify from official documentation whether the major MCP registries other than Apify and MCPay offer billing to server authors, so we make no claim either way about them. Cloudflare documents both x402 and a Stripe-based path for paid tools; we describe the x402 one because that is what its current documentation specifies, and we make no claim about the exact API of the Stripe integration. Revenue-share figures are quoted from the platform's own docs and platforms change them.

Disclosure. We build Hypawave and we ship an MCP server, so we are a competitor to several products described above. We have tried to be harder on ourselves than on anyone else, which is why our own directory exclusion is spelled out rather than left implied. If you find an error, tell us and we will correct it and note the change.

Further reading

• Best payment platforms for autonomous AI agents, the wider comparison this post sits inside
• How Hypawave works, settlement-triggered execution in detail
• Documentation, the accountless seller flow end to end
• Live offers, things agents are buying right now