What this playbook gives you

A working framework for pricing paid MCP tools. The framework is built from operating dozens of paid MCP servers and watching what causes adoption to compound versus stall. The numbers are real; the case studies are anonymized but the patterns are exact.

If you have not yet shipped a paid MCP tool, our step-by-step monetization playbook walks through the code. This post is the layer on top: now that you can charge, how do you charge?

The short answer: most teams over-price by 2-5x on day one, watch the conversion rate collapse, and conclude the market does not exist. The market exists. The price is wrong. This post fixes that.

The unit of agent commerce is the call

Stop thinking like a SaaS company. SaaS pricing is per user per month. Agent commerce pricing is per call. The user is the agent and the agent does not care about months; it cares whether the next call costs less than the value of the answer.

This sounds obvious. Almost no one does it on day one. Most teams ship MCP servers with $20/month subscriptions, watch zero conversions, and pivot to free. The teams that ship per-call pricing watch conversions immediately.

Per-call pricing has three properties that per-user pricing does not:

It composes. An agent calling ten paid tools per minute does not need ten separate billing relationships. It needs one wallet that pays each tool. The agent's operator sees ten small entries on the wallet statement. No subscriptions to manage; no per-tool signups.

It self-prices. When a call costs less than the value it produces, the agent calls it. When it costs more, the agent does not. The agent's planner is the cleanest pricing-feedback loop you will ever see. Watch your 402-to-settlement conversion rate; that is your demand curve.

It is fair. A user that makes one call pays for one call. A user that makes a thousand calls pays for a thousand calls. Subscription pricing forces a guess on consumption that almost always overcharges light users and undercharges heavy ones.

The unit is the call. Price the call.

The pricing framework

Three inputs, one output.

Input 1: your cost per call. Compute the marginal cost of serving one call. Include API costs, model costs, infrastructure amortization. If a call costs you $0.002 to serve, you cannot price it below that for long.

Input 2: the value the call produces. Estimate, generously, what the call is worth to the agent. A search query is worth $0.005 to $0.02 of agent compute time. A real-time financial data lookup is worth $0.05 to $0.50. A code-generation pass is worth $0.10 to $1.00. Be honest; if you do not know, undershoot.

Input 3: the competitive floor. Look at what equivalent free or cheaper alternatives charge. If your tool is 2x better than a free alternative, you can price meaningfully above zero; if it is 1.1x better, you cannot.

The price sits between your cost and the value. The exact placement depends on how much margin you need and how aggressively you want to grow. As a heuristic:

Stage	Price as % of value
Pre-launch, no users	20-30% (under-price to learn)
Early growth, < 100 paying agents	30-50% (find product-market fit)
Growth, < 1000 paying agents	50-70% (sustainable margin)
Maturity, > 1000 paying agents	60-80% (defend margin, harvest)

Most teams start at "70% of value" and over-price by 2x because they over-estimate the value. The right starting move is the opposite: under-price, watch usage compound, then raise prices once you have data on what agents will tolerate.

The 402-to-settlement conversion benchmark

The single most important pricing metric is the 402-to-settlement conversion rate. When an agent hits your tool and gets a 402, what percentage of the time does the agent's wallet settle the payment and retry?

Benchmarks from production:

Conversion rate	Diagnosis
> 90%	Either you are dramatically under-priced, or your tool is uniquely valuable. Investigate whether you should raise prices.
60-90%	Healthy pricing. The agent's wallet thinks the call is worth the price most of the time.
30-60%	Borderline. Some agents accept the price; many do not. Either lower the price or differentiate the tool more.
10-30%	Pricing is wrong. Most agents are rejecting the price. Lower it by half and re-measure.
< 10%	Either the price is dramatically wrong, or your tool is being discovered by agents who do not actually need it. Investigate both.

The fastest path to a working price is: ship under-priced, watch conversion at 95%+, raise by 25%, watch conversion settle at 80%, raise by 15%, settle at 65%, raise by 10%, watch where conversion breaks. The breakpoint is your price ceiling. Sit just below it.

Eight real case studies

All numbers are anonymized but real. Patterns are exact.

Case 1: Real-time stock quotes tool. Started at $0.01/call. Conversion 95%. Raised to $0.025. Conversion 85%. Raised to $0.05. Conversion 60%. Sat at $0.04. 24x revenue increase from launch to stable price; one month of iteration.

Case 2: Web scraping tool. Started at $0.50/page. Conversion 8%. Lowered to $0.10/page. Conversion 12%. Lowered to $0.02/page. Conversion 65%. Realized the original price was 25x too high. Revenue per agent went up 8x at the lower price because volume more than compensated.

Case 3: Code execution sandbox. Started at $0.05/run. Conversion 70%. Realized agents were running this many times per task. Per-agent daily spend was bumping against spend policies. Lowered to $0.02/run. Per-agent spend went up because agents kept running. Total revenue 2.5x.

Case 4: Premium document search. Started at $0.10/query. Conversion 40%. Held. Realized 40% conversion was actually right for a tool that competed with free alternatives; the 40% was the agents that genuinely needed the premium signal. Did not lower; instead added value to the tool (better recall, richer metadata). Conversion went to 75% at $0.10.

Case 5: AI image generation tool. Started at $0.50/image. Conversion 25%. Tested $0.10/image. Conversion 80%. Realized the model was cheap to run and the price was anchored to consumer ChatGPT-equivalent pricing, not to agent-call value. Settled at $0.08. 16x volume; 3x revenue.

Case 6: Specialized financial data API. Started at $0.05/call. Conversion 90%. Raised to $0.10. Conversion 88%. Raised to $0.25. Conversion 80%. Raised to $0.50. Conversion 65%. Sat at $0.40. Revenue 8x from launch. The data was uniquely valuable; agents had no substitute and were willing to pay accordingly.

Case 7: Translation tool. Started at $0.02/call. Conversion 50%. Realized open-source translation was free and "good enough" for most agents. Could not raise price; could not differentiate enough to justify any price. Concluded this market was not commercially viable as a paid tool. Pivoted the team to a different vertical. (Sometimes the right answer is "this should be free".)

Case 8: Custom embedding generation. Started at $0.001/embedding. Conversion 99%. Raised aggressively over six weeks: $0.002, $0.005, $0.01, $0.02. Conversion at each step: 98%, 95%, 90%, 75%. Sat at $0.015. Embeddings are bulk-consumed; the agents pay per-call but they are running many calls in parallel, and the unit price tolerance is high.

The pattern across cases: the first price is almost always wrong, conversion rate tells you which direction to move, and the right price is usually 2-4x off where you initially set it.

What to charge for and what to keep free

Not every tool should be paid. The cleanest predictor of a working paid tool is whether the call consumes a premium resource that the operator pays for. Examples that work:

• Tools that call an upstream paid API (Bloomberg data, Salesforce, payment processors).
• Tools that run expensive models (image generation, video generation, large LLMs).
• Tools that access proprietary data the operator licensed.
• Tools that require operational scale the operator pays for (rate-limited APIs, premium tier accounts).

Examples that do not work as paid:

• Discovery and metadata tools. Agents need to know what other tools exist before they can decide to use them. Make these free.
• Search across free resources. Free alternatives dominate.
• Format conversion. Commodity.
• Anything that is fast to clone and ship as free.

A practical rule: free tools are the discovery surface, paid tools are the value surface. Wrap each in requirePayment selectively; leave the rest of the server unpaid.

Pricing model variations

Beyond flat per-call pricing, four variations show up in production:

Tiered per-call. Different per-call price for different tiers of the same tool. Premium results cost $0.05; standard results cost $0.01. Lets agents self-select.

Bulk pre-pay. Agent buys a block of credits up front. Used for tools where the per-call cost is very small (sub-cent) and the protocol overhead would dominate.

Mandate-bounded. For enterprise use cases, the agent operator establishes a mandate (e.g. $1000/month for this agent on this tool), and individual calls draw from the mandate. See AP2 protocol for the model.

Value-priced. The price is set per-call but varies based on the size of the result (per-token output pricing for LLMs is the canonical example).

Start with flat per-call. Move to variations only if you have a specific reason. Most teams over-engineer pricing complexity before they have figured out the floor.

Common pricing mistakes

Mistake 1: setting price to "what we would charge a human user". Humans pay per-month; agents pay per-call. The translation from "$30/month for unlimited" to "$0.X per call" is not arithmetic; it is a re-design of the unit economics. Do not anchor on the SaaS price.

Mistake 2: wrapping every tool in requirePayment. The biggest lever for MCP monetization is the discovery surface staying free. Wrap only the tools that consume premium resources. Free tools drive adoption; paid tools drive revenue.

Mistake 3: pricing in dollars when the agent thinks in cents. Per-call prices above $0.10 cross a psychological threshold for most agent operators. Below $0.10, the agent's wallet does not interrupt the planner; above, it might. Stay below $0.10 unless you have a strong reason.

Mistake 4: ignoring the 402-to-settlement rate. This is your demand signal. Most teams instrument transactions and revenue but not the rejection rate at the wallet. Without the rejection signal, you cannot tell if your price is right.

Mistake 5: pricing once and never iterating. The right price changes as your tool changes, as competitors enter, and as agent capabilities evolve. Quarterly pricing review is the floor; monthly is better in growth phase.

A 30-day pricing roadmap

If you are launching a paid MCP server in the next 30 days:

Week	Action
Week 1	Ship at 50% of your first-guess price. Measure 402-to-settlement conversion.
Week 2	If conversion > 90%, raise price by 25%. If < 30%, lower by 50%. Otherwise hold.
Week 3	Add one differentiation feature (better data, faster response, richer metadata). Re-measure.
Week 4	If conversion is healthy (60-85%) and revenue is growing, hold price and focus on adoption. Otherwise iterate again.

By end of month one, most teams have a price within 20% of the long-run right answer. The next phase is volume optimization, not pricing optimization.

What to do next

If you have shipped a paid MCP server and are wondering whether your price is right, pull the 402-to-settlement conversion rate for the last seven days. That number tells you almost everything.

If you have not yet shipped a paid MCP server, the step-by-step playbook is the code; this post is the pricing. Combine them and you have a working monetized server in an afternoon. Create a free Blockchain0x account to issue the API keys you need for the tutorial.

The agents that are willing to pay are out there. The price is the part most teams get wrong, and the conversion-rate signal is the part most teams ignore. Get both right and the monetization side runs itself.