There's a line going around developer forums in 2026: the average price of an MCP server is $0. It's mostly true, and it's both the problem and the opening. The problem is that "give it away" became the default before anyone thought hard about value. The opening is that a genuinely useful tool, priced deliberately, stands out in a sea of free ones — and the agents calling it can pay without you building a billing system.

This post is about the part that comes after "should I charge?" (yes, if it's useful) — namely how much, for what unit, and the metering details that turn out to be the actual hard work. If you haven't wired up payments yet, start with MCP server monetization with x402; this is the pricing companion to it.

First, the three models

MCP standardizes how an agent discovers and calls your tool. That leaves you three ways to put a price on it:

Free (as a funnel). Legitimate when the server is a loss-leader for something else you sell, or when you're farming adoption and reputation. Illegitimate as a default you backed into because pricing felt hard. Free is a strategy, not a fallback.
Subscription / seat. A flat monthly fee per operator. Fits when the same known customer uses the server heavily and predictably, and when you want recurring revenue you can forecast. The catch: it requires onboarding — accounts, plans, someone to sign up — which is friction for the long tail of agents you'll never meet.
Per-call (pay-per-call). Each tool invocation carries a price; the agent's runtime pays in the request. Fits when callers are autonomous, sporadic, and anonymous — exactly the population MCP unlocked. No signup, no plan to provision, no relationship required.

Most servers should default to per-call and add a subscription path only once they have heavy, named, repeat customers. We made the general version of that argument in pay-per-call vs subscriptions; it applies cleanly to tools.

Choosing the unit you charge for

Per-call doesn't mean "one flat price for everything." The unit is a decision:

Per tool call — simplest; every invocation of a priced tool costs the same. Good when your tools are roughly equal in cost and value.
Per tool, tiered — a cheap lookup and an expensive deep_analysis shouldn't cost the same. Price each tool to match what it costs you and what it's worth to the caller.
Per result / per unit of work — when a single call can do a little or a lot (one record or ten thousand), price the work, not the call. Harder to meter; fairer when call sizes vary wildly.

Pick the coarsest unit that still reflects value. Over-granular pricing creates metering pain (next section) for accuracy nobody asked for.

The hard part: metering

This is what developers underestimate. Charging real money for tool calls surfaces a cluster of problems that "it's free" let you ignore:

Idempotency and dedup. Agents retry. Networks hiccup. If a tool call is attempted twice, you must charge once. Without idempotent handling you either double-charge (and lose trust) or undercount (and lose money).
Per-agent caps. A runaway agent in a loop can hammer a priced tool thousands of times. You want guardrails — caps that protect both the caller from a surprise bill and you from being a denial-of-wallet target.
Sub-cent aggregation. If a tool costs a fraction of a cent, you can't run each call through a heavyweight charge — the overhead would exceed the price. The calls have to aggregate.
Charge-on-success, not on-attempt. If the tool fails, the caller shouldn't pay. That means payment and execution are bound together: verify payment, run the tool, and if it fails, don't keep the money. This is the fail-closed discipline — when anything is uncertain, you don't serve and don't charge.

These are real systems problems, and they're the reason "just add Stripe" doesn't fit tool calls — the per-transaction overhead alone breaks sub-cent pricing.

How x402 absorbs most of it

The reason per-call MCP pricing is practical in 2026 is that the protocol and the middleware handle the parts above so you don't hand-roll them:

The agent's runtime funds and attaches payment proof on retry — you never touch a wallet or hold the caller's funds.
Payment verification and tool execution are bound in one path: the handler runs only after payment verifies, and the fail-closed default means a failed call doesn't silently charge.
The challenge/verify flow carries a nonce, so a replayed payment proof doesn't pay twice — that's idempotency you get from the protocol rather than building.
Earnings settle to your wallet automatically; you don't reconcile a ledger of sub-cent charges by hand.

What's left for you is the part only you can decide: the price.

Setting the number

A workable process, borrowed from how to price an API for AI agents:

Find your floor. What does one call cost you to serve (compute, upstream APIs, data)? You price above this.
Anchor to value, not cost. What does the result save or earn the agent's operator? A tool that replaces a $0.10 task can charge a meaningful slice of that.
Start low and visible. Begin near the floor, watch usage, raise it where demand proves the value. Underpricing is recoverable; a reputation for gouging agents is not.
Prove it in test mode first. Run the full pay-call-serve loop with no real money so you can see the meter behave before you flip to live.

The bottom line

The "$0 average" isn't a law of nature — it's the residue of charging being hard before the tooling existed. It exists now. Choose per-call as your default, price each tool to its value, let the protocol handle dedup, caps, aggregation, and fail-closed charging, and prove the loop in test mode before going live. A useful tool with a deliberate price beats a useful tool you gave away because the meter scared you.

Next steps

Wire up payments first: MCP server monetization with x402
For MCP authors: monetizing an MCP server
The pricing fundamentals: how to price an API for AI agents
The integration, per stack: SDKs · start free: create an account

How to price (and meter) an MCP server