A tool priced at $0.01 per call does not mean a research task costs $0.01. The assistant may search first, read several sources, find a gap and query again, then call a model to put the results together.
When comparing tool costs, connect the unit of billing to how much one task actually uses. This is also where "installing an MCP server for free" and "completing a task for free" are easy to confuse.
First, Work Out Which Layer You Are Paying
MCP is an open protocol, and tool code may be released under an open-source license. That governs how the code can be used. It does not decide whether the service behind it charges, and it does not remove the resources needed to run the program.
One tool workflow can involve several bills: call or data fees from upstream APIs, the assistant client's subscription, model input and output charges, and compute, storage and logging if you host services yourself. Not every run incurs all of them, but a budget cannot be built from just one price.
Avoid double counting as well. If model usage is already included in the client plan, do not add it again at the standalone API price. If a remote tool's unit price already covers its own model or hosting costs, the caller should check the price actually paid for the service rather than estimating the provider's bill and adding it on top.
Working Through a Hypothetical Task
The figures below are a set of assumptions chosen to explain the calculation. All amounts are in US dollars; they are not current prices of any product, this site's pricing or a measured budget. Assume a research task makes 20 initial calls and 5 additional billed calls, and the API charges $0.01 per call:
| Cost item | Assumed basis | Amount (USD) |
|---|---|---|
| Initial API calls | 20 calls at $0.01 each | 0.20 |
| Additional billed calls | 5 calls at $0.01 each | 0.05 |
| Model usage | Assumed model input and output for this task | 0.08 |
| Own infrastructure | Assumed share of compute, storage and similar costs | 0.02 |
| Total | Sum of the four items | 0.35 |
In this example the unit price is $0.01 and the task costs $0.35. You need both numbers, and neither replaces the other.
Additional calls can come from follow-up queries, pagination, regenerated searches or retries. The table counts requests that were actually billed. Whether failed requests are charged and whether retries are billed separately depend on each service's rules; an HTTP status code alone does not prove a cost of zero.
What Per-Call Prices Look Like Today
The $0.01 in the example is close to what the market charges. On November 11, 2026, our directory had 3,628 reachable x402 services with a recorded price. Prices cluster around one cent: 2,674 of them, about 74%, asked for $0.01 or less, and the median was exactly $0.01. The cheapest 10% asked for $0.003 or less, the most expensive quarter for $0.02 or more, and the top 10% for $0.05 or more. 114 services charged $1 or more for a single call.
These are list prices taken from each service's payment requirements, the most it asks for one request, not what callers ended up paying. They are still useful for planning: at the median price, the 25 calls in the example come to $0.25 before any model or infrastructure costs. At the 90th percentile they would come to $1.25.
How Much a Tool Returns Also Affects Cost
If the content a tool returns goes into the model's context, it affects model usage. Reading a full long document, extracting only the relevant passages, returning paginated results or returning document links each change usage differently. The exact cost still depends on the client's and the model's billing rules.
Trimming irrelevant content helps twice: the assistant finds the evidence it needs more easily, and repeated reading goes down. One approach is to return titles, summaries and sources first and fetch the full text only when needed. Do not drop key conditions to save usage, though, or the assistant may need more follow-up queries or may reach conclusions nobody can check.
Batching queries is not automatically cheaper either. If a service charges per returned record rather than per request, merging requests mainly changes how calls are made and may not reduce the bill. Check the billing unit before deciding whether an optimization changes the cost.
x402 Handles Payment, Not Your Budget
x402 lets a service state a payment requirement as part of the HTTP exchange, and a supporting client completes the payment under the matching scheme. It lets pay-per-call access be handled by a program; it does not decide how much one task should spend.
The x402 documentation says the standard itself has zero fees built in. That does not make resources free, and it does not mean every network and settlement scheme is free of transaction costs. Check the service price, the payment scheme used, and which costs are already included in the quoted price.
The application still has to set the task budget, the services that may be called and the authorization required. A tool with a very low unit price can still add up to more than expected when it is queried repeatedly. Budget control should follow the task and the running total, not just the amount of each call.
Compare Services on the Same Kind of Task
To compare two tools, fix the research subject, the material in scope and the deliverable first, then record each tool's billed calls, returned content, model usage and final result. Two outputs of different quality cannot be ranked by their bills alone.
Fixed costs such as subscriptions and infrastructure need a stated allocation method. With fewer successful tasks, each one carries a larger share, and the cost of retries and unfinished tasks should not disappear from the record. For your own workflow, keeping a running record of actual bills and delivered results is more useful than borrowing someone else's industry cost ratio.
The unit price tells you the cost of entry; the task cost is what you budget with. Only when both are tied to the same task record can you see where the money goes and which changes actually reduce usage.