A fair price for a tool that AI helpers use follows two things: what the buyer's helper actually consumes, and how fast the value behind your tool goes stale. Charge per call for a tool that judges something. Charge per lookup or per month for facts a machine must not guess. Charge per finished result only when you can prove the result.
The problem
You own a company that keeps a price book for building materials. Contractors have paid for it for years. Now their AI helpers want to pull prices straight from your system, hundreds of times a day. Your developer says it is ready to switch on. Then someone asks the question you have been avoiding. "What do we charge?"
You have no idea. Per lookup feels like nickel-and-diming. A flat monthly fee feels like giving it away to the heavy users. Charging per finished estimate sounds fair, but you cannot see the estimate. You searched "how to price ai agents" and got advice written for people selling chatbots.
So the switch stays off, and the contractors' helpers use a free source that is six months out of date. Everybody loses.
Why this keeps happening
Most pricing advice starts with the buyer. Yours should start with what you are selling, because different kinds of tools go stale at different speeds. That speed sets your cost of staying useful, and your cost of staying useful is the one cost that never stops.
Most tools that AI helpers call speak MCP, a standard way for AI helpers to use tools. When people search "mcp server pricing models" or "how to charge for an mcp server", they find lists of models with no way to pick one. Here are the seven kinds of tool worth selling, and what each one naturally costs.
| What you sell | Plain example | How fast it goes stale | Natural price |
|---|---|---|---|
| Facts a machine must not guess | Price books, registries, permit records | Monthly | Monthly fee or per lookup |
| How another system behaves right now | What a partner's software accepts this month | Every time they release | Monthly fee |
| Rules with dates and a named keeper | Quoting rules, consent rules, licence terms | When the rules change | A retainer for keeping them current |
| A checker that judges a result | Does this summary match the record? | Gets better with use | Per call (pay per call mcp tools are usually checkers) |
| Past examples with the right answers | Graded history used to test a model | Each new model release | Licence per version |
| Something only a company can hold | A signing certificate, a sending domain | Yearly | Yearly |
| Heavy computing cheaper to rent | A specialised machine you already run | Constant | Counted use |
Two kinds get better the more they are used: a checker, and facts with your own scoring on top. Every good outcome sharpens the judgment. Everything else is a maintenance job. If you own a data set, your price must cover refreshing it every month whether or not anyone calls.
The cost of getting this wrong is not just a low price. A monthly fee on a spiky tool gets cancelled after the one busy month. A per-call price on a tool with wildly different costs makes buyers pay for your failures. A per-result price with no record of the result becomes a per-attempt price with an argument attached.
How to fix it
- Name what you sell. Find your tool in the table above. If it is two things, price the two parts separately.
- List your costs for one use. Data licence per record, model use per call, computing, and any human review. Use the worst realistic call, not the average, because AI helpers retry when something fails.
- Pick the model that matches the shelf life. Per call for judgment. Monthly or per lookup for facts. A retainer for rules. Yearly for things only a company can hold. This is usage-based pricing for ai agents done by shelf life, not by guesswork.
- Set the number and do the margin test. After payment fees, refunds and the platform's cut, is there money left on the worst call? If one failed call wipes out ten good ones, add a small minimum per use or move the expensive part to a monthly fee.
- Compare it to the human it replaces. Your price for a week of use should be obviously less than the hours of staff time it saves. If it is not obvious, lower the price or raise what the tool does.
- Charge per finished result only if you can prove it. Outcome-based pricing ai agents can buy needs three things. A definition of done the buyer agreed to, a signed record that it happened, and a way for the buyer to reject it and not pay.
Two sellers who already do this publish the rule in one sentence. Apify, a store where makers sell automation tools it calls Actors, tells them to pick one billable event.
"Pick one event that best represents the main value of your Actor."
Intercom's support helper charges once per finished conversation, and says so plainly on its price page.
"You're only charged for one outcome per conversation, even if Fin takes multiple actions."
That is what a definition of done looks like: one sentence a buyer can check.
Here is a worked example in BlueBear's unit, credits, where one credit is one US dollar. Say you publish a permit-record cleaner, which is facts plus a little behaviour tracking. You could price it at, for example, 0.05 credits per lookup, with a few free sample calls. A roofing agency's helper that pulls 400 permits a week would spend 20 credits a week. The agency can see that number before it subscribes.
Now say you also publish a checker that judges whether a written permit summary matches the record. That is a per-call product, for example 0.10 credits per judgment. The helper calls it once per summary, so the two together cost the agency 60 credits a week. Your job is to make 60 credits obviously less than the hour of a coordinator's time it replaces. These figures are illustrations. Your own costs decide yours.
For a sense of the market as of September 2026: Composio prices its own hosted connectors with a free tier, a Pro plan, and a per-call rate of $0.0003. That is where plain, commodity connection calls sit. Composio also bills its premium tools at the provider's cost plus 5 percent, shown as its own line. Do the same with any cost you pass through. Apify lets makers define billable events and pays the maker 80 percent of what buyers spend, less platform costs. Stripe publishes an experimental recipe for one-time purchases of this kind of tool, and its own sample tells you to add access checks and limits yourself. Nobody publishes a price list for checkers, rules or graded examples, because few people sell those yet. That is the room a specialist tool has.
What BlueBear's marketplace does about it
BlueBear's marketplace lets you put one price on your tool and get paid when it is used. Buyers pay in credits, one credit is one US dollar, and the price sits on your public page where a buyer or their helper can read it before spending anything.
Each use is counted and produces a signed receipt: what ran, for whom, at what price, and what came back. Your earnings are recorded from those receipts, one line per job. If a buyer rejects a result, that job is refunded and your line is reversed. That is what makes per-result pricing honest: there is a record to point at. Some people say per-result pricing is easy to game, because a tool could mark every job done. The reject and refund path is the answer. A rejected job pays nothing, and the receipt shows it. A buyer's helper can only spend up to a limit the buyer set per request, so a retry loop cannot run up a surprise bill against you or them.
What is still early. The marketplace is a pilot. Publishing is by invitation, one pricing model per listing, and BlueBear sets up the listing on your behalf. Payouts are done by hand. If you sell facts, keeping them fresh is your job as the named keeper, and buyers will expect you to say how often you refresh.
What to do next
Fill in steps one and two this week: what kind of tool you sell, and what one use costs you on a bad day. Then pick a number and run the margin test. If you sell facts, read what buyers expect you to promise about freshness before you publish.
Two more pieces show the buyer's side of your price. Cost per completed workflow shows how a buyer adds up your price with everything else in their process. Tool calling on a budget shows why a helper's retries land on your count, and what buyers do about it.
Once your model is set, read how to charge for your tool without building billing yourself. Or browse the public marketplace page to see how a price appears on a listing.
Questions people actually search for
- how much should i charge per use of my tool
Start from your worst realistic cost for one use, not the average, because AI helpers retry when something fails. Add data fees, computing, any human review, the platform's cut and a small allowance for refunds. Then check that the result is still clearly below the cost of a person doing the same task. On BlueBear prices are in credits at one US dollar each. A lookup might be, for example, 0.05 credits and a judgment 0.10 credits. Those are illustrations, not benchmarks.
- should i charge per call or a monthly fee
Charge per call when each use is worth about the same and the buyer's helper decides when to call, which is the shape of a lookup or a checker. Charge a monthly fee when what you sell is freshness or availability and use is steady, which is the shape of a data set you refresh every month. If use is spiky and light, a monthly fee gets cancelled after one heavy month. If calls vary wildly in cost, per call makes buyers pay for failures.
- what is outcome-based pricing for ai agents
Outcome-based pricing ai agents can buy means charging for a finished, checkable result instead of for each attempt: a matched invoice, a released report. It needs three things you may not have yet. A definition of done that the buyer agreed to, a signed record that it happened, and a way for the buyer to reject the result and not pay. Without a receipt and a refund-on-reject rule, per outcome quietly turns into per attempt, and the argument starts.
- how do i know if my price covers my costs
Run one test. At the price you set, is there still money left after payment fees, refunds and the platform's cut, on your worst realistic call? List your variable costs first: data licence per record, model use per call, computing, and human review. If one failed upstream call wipes out ten good ones, add a small minimum per use or move the expensive part to a monthly fee. If you cannot list the costs, you are not ready to price.