How we evaluate

Charging for an MCP server is judged on who your callers are and how they pay. The criteria that matter:

• Machine-payable. Can a caller pay with no human signup, mid-task? Agents cannot complete an account-creation flow, so for agent callers this is decisive.
• Per-call versus recurring. Does the model charge per use or per subscription period? Occasional machine callers want per-call; ongoing human customers often want a plan.
• Setup effort. How much do you build to start charging, and how much do you maintain?
• Micropayment economics. Can it price sub-cent and few-cent calls, which a card-based subscription cannot?
• Control and ownership. Do you keep pricing and the customer relationship, or hand them to a platform?
• Trust and reach. Can callers you do not know in advance pay you, or only pre-registered customers?

No option wins every criterion, so the answer turns on one question.

The dividing question

Before comparing options, answer one question: are your callers machines or people? It divides the field cleanly. If your MCP server is meant to be reached and paid by agents, often agents you do not know in advance, you need a machine-payable, per-call solution, because an agent cannot sign up for an account or enter a card. If your customers are humans or businesses with an ongoing relationship, a subscription or metered plan fits, and a traditional processor serves it well.

Most of the apparent disagreement about the best MCP payment solution dissolves once you fix this. The rest of this comparison is really about which option fits which side of that line, so decide it first and let it guide the rest.

The five realistic options

In 2026 the realistic ways to charge for an MCP server are an x402 per-call solution, rolling your own x402, API-key subscriptions, metered billing, and marketplace billing. They split along the machine-versus-human line above.

Option 1: x402 per-call

An x402 per-call solution gates the MCP server's HTTP route so each call settles a payment in USDC. With the Blockchain0x adapter, you register createX402Plugin (Fastify) or createX402Middleware (Express) in front of the route with per-route pricing; an unpaid call gets a 402, a paid one settles on Base, and the MCP server runs.

It fits best when your callers are agents paying per use with no signup, which is the native MCP-plus-agents case. It needs the server on the Streamable HTTP transport, and it prices per route rather than per individual tool, so you arrange tools across routes. For machine callers and micropayments, this is the model that matches, and it is the focus of how-to-build-a-paid-mcp-server.

Option 2: Roll your own x402

Because x402 is an open protocol, you can implement the per-call model yourself against USDC, with no provider in the settlement path. This gives the same machine-payable per-call behavior as Option 1 with maximum control and no platform fee on the protocol.

It fits best when you have the engineering capacity and a specific reason to own the whole stack. The cost is that you build and maintain wallet management, the 402 handling, settlement verification, per-call attribution, and the operational tooling that a managed adapter provides. Choose it when control genuinely outweighs that build-and-maintain burden, not by default, since for most teams the managed adapter reaches the same result faster.

Option 3: API-key subscriptions

The traditional approach gives customers an API key after they sign up and subscribe, and gates the server on a valid key. A processor handles the recurring billing, and you check the key on each request.

It fits best when your customers are humans or businesses on an ongoing plan who expect a monthly subscription and an invoice. It does not serve machine callers you do not know, because they cannot complete signup, and it does not price per call naturally. Choose it when you sell to known customers with a relationship, not when arbitrary agents should be able to pay you per use.

Option 4: Metered billing

Metered, usage-based billing tracks each call and bills the customer periodically for their usage, typically through a processor's metered product. It keeps the per-use feel while still running on accounts and monthly invoices.

It fits best when customers want to pay for what they use but still operate as account-holding, invoiced customers, a common B2B shape. Like subscriptions, it assumes a signup and a billing relationship, so it suits known human or business customers rather than arbitrary machine callers. It is a middle ground: usage-based like x402, but account-based like a subscription, which fits human customers who dislike flat fees.

Option 5: Marketplace billing

Some MCP marketplaces and platforms handle billing for servers listed on them, taking payment from callers and paying you. This offloads the payment work entirely and can bring distribution.

It fits best when you want a fast start and the marketplace's reach, and are comfortable with a platform dependency. The trade is control: the platform sets terms, may own the pricing and customer relationship, and takes a cut. Weigh the convenience and distribution against the dependency, the same calculation as any platform between you and your callers. It can be a good on-ramp that you later supplement with your own per-call path.

You can combine two

These options are not mutually exclusive, and a server that serves both machines and people often runs two. A common shape is a per-call x402 route for agent callers alongside an API-key subscription for human customers who prefer a monthly plan, both in front of the same MCP server. The agent pays per call with no account; the human signs up once and is invoiced.

Running both costs a little more wiring, but it lets you reach every kind of caller without forcing one model on all of them. If your audience genuinely spans autonomous agents and signed-up customers, treat the two payment paths as serving two audiences rather than picking a single winner, and gate each route accordingly.

Summary comparison

How to pick

Answer the dividing question and the choice follows. If your callers are agents paying per use with no signup, choose an x402 per-call solution; the Blockchain0x adapter gives it without building settlement yourself, or roll your own if control is paramount and you have the engineers. If your customers are humans or businesses on a relationship, choose API-key subscriptions or metered billing through a traditional processor. If you want a fast start with distribution and accept a platform dependency, a marketplace can carry the billing.

For the common MCP-plus-agents case, where the whole point is that any capable agent can call and pay, x402 per-call on USDC is the model that fits, because it is the only one that lets a caller you have never met pay you mid-task. To build it, see how-to-build-a-paid-mcp-server; for the strategy around it, see mcp-server-monetization. Pricing is on the pricing page.