AI agents can discover paid services through configured endpoints, MCP or A2A manifests, identity registries, and searchable x402 catalogs. But discovery should never lead directly to payment.
The reliable path is:
This separation matters because a catalog entry, a tool definition, and an HTTP 402 Payment Required response answer different questions. The catalog says a service may exist. The tool schema says how it may be called. The payment requirement says what this request currently costs. None of them, alone, proves that the result will be useful or that the agent is authorized to buy it.
The practical unit of machine commerce is therefore not one listing. It is a service descriptor plus a request-bound quote plus a local purchasing decision.
Discovery Produces Candidates, Not Permission to Buy
A human can read a pricing page, recognize a familiar brand, compare plans, and decide whether a purchase feels reasonable. An agent needs those judgments decomposed into data and policy.
Four records should remain distinct:
Service descriptor: relatively stable metadata about capability, endpoint, input, output, supported protocols, and provider identity.
Payment quote: current terms for a specific request, including amount, asset, network, payment scheme, and recipient.
Purchase decision: the agent's policy result after checking compatibility, budget, trust, and expected value.
Outcome record: what was paid, what was delivered, how long it took, and whether the result helped complete the task.
Collapsing these records creates predictable errors. If a directory price becomes the executable quote, stale metadata can trigger an unintended payment. If an x402 requirement becomes proof of quality, any compatible endpoint can appear worth buying. If a wallet balance becomes purchase permission, the agent can spend funds outside the user's purpose.
A better state machine makes each transition explicit:
Each state should have its own timestamp, evidence, and failure reason. An endpoint can be discoverable but incompatible, compatible but overpriced, affordable but unauthorized, paid but undelivered, or delivered but useless. “Available” is not a sufficient status for any of those cases.
A Service Descriptor Must Answer “Can It Do the Job?”
Discovery begins with a task, not a marketplace. A research agent might need a current company filing in structured JSON. A coding agent might need a sandboxed test run. An operations agent might need an address-validation result under a latency limit.
The discovery query should express those constraints before ranking candidates. A useful internal descriptor could look like this:
This is an illustrative local record, not an MCP, x402, A2A, or ERC-8004 schema. Its job is to normalize several discovery channels into one candidate model.
Direct and curated discovery
The simplest agent uses an administrator-approved list of service descriptors. This limits coverage, but it gives the organization control over identity checks, contracts, and supported payment methods. Enterprise agents may prefer this model when the cost of trying an unknown service exceeds the benefit of broader search.
Tool and agent manifests
MCP tool definitions expose names, descriptions, input schemas, optional output schemas, and behavior hints. A2A Agent Cards describe an agent's identity, skills, endpoint, capabilities, and authentication. These formats help a caller understand what it can invoke. Their core schemas do not create a universal price contract.
That means an agent can discover a callable tool without knowing whether it is free, subscription-gated, or payable per request. Pricing needs a compatible extension, catalog, or live payment handshake.
Identity registries
ERC-8004 registration metadata can advertise service endpoints, including MCP and x402 interfaces, and indicate x402Support. It gives indexers a stable identity reference and gives callers a path to reputation or validation signals. The description may mention pricing, but ERC-8004 is not a live price oracle. Its own security boundary is important: registration can bind metadata to an onchain identity without proving that every advertised capability works as claimed.
Paid-service catalogs
An x402 catalog can index payment-gated endpoints and expose payment metadata alongside capability descriptions. CDP's Bazaar, for example, supports natural-language search and filters such as network, asset, payment scheme, merchant, protocol extension, and maximum USD price. It can reduce a large catalog to a technically plausible shortlist.
That convenience has a tradeoff. A catalog sees indexed metadata and prior activity, not the full value of the result for the agent's current task. Catalog relevance should influence candidate ordering, never replace request-time validation.
Machine-Readable Price Is More Than an Amount
Two services that both display 0.01 may have incomparable prices. One may charge per request, another per thousand records, and another may authorize a maximum before settling actual usage. An amount is meaningful only when its unit and conditions travel with it.
Price field | What the agent must determine | Failure if omitted |
|---|---|---|
Billing basis | Per request, token, byte, second, task, record, or outcome | Compares different products as if they were equal |
Amount | Exact charge, minimum, estimate, or maximum authorization | Treats a ceiling as the likely final cost |
Asset and decimals | Token contract or currency plus canonical decimal rules | Misreads smallest-unit integers as display values |
Network | Where authorization and settlement occur | Selects an unsupported wallet or wrong asset instance |
Payment scheme | Exact, variable, deferred, or another supported method | Signs a flow the client cannot verify correctly |
Recipient | Address or merchant identity receiving value | Pays a destination not approved for the service |
Scope | Inputs, output class, quality tier, and included usage | Buys a result that does not satisfy the task |
Validity | Quote age, timeout, expiry, or conditions for requoting | Pays terms that no longer apply |
External costs | Network, conversion, retry, and operational overhead when applicable | Understates the all-in cost |
Delivery terms | Success definition, retry, refund, or credit behavior | Cannot evaluate failure recovery |
The agent should normalize economic terms before comparing candidates. A raw token amount requires trusted asset metadata to resolve decimals. A display price in dollars may require conversion into the wallet's available asset. A per-token model needs an upper-bound estimate based on the planned input and output. An up-to authorization should be tested against the spending cap at its maximum, even when the expected settled amount is lower.
One useful internal representation separates the seller's terms from the buyer's calculation:
The identifiers are intentionally abstract. Production code should resolve network, asset, decimals, and recipient from trusted configuration rather than accepting human-readable symbols at face value.
Treat the HTTP 402 Response as the Fresh Quote
Discovery metadata is a hint. The protected endpoint is the source of current payment terms.
In the current x402 HTTP flow, the agent first sends the intended request without payment. The resource server can respond with 402 Payment Required and a machine-readable PAYMENT-REQUIRED header. The payload includes an accepts array of payment options. Each option identifies conditions such as scheme, network, asset, amount, recipient, and timeout information. The buyer selects an option it supports, creates a payment payload, and retries the request.
Before signing, the agent should convert that response into a local quote record bound to the attempted request:
Again, the fingerprint and local quote-age field are buyer controls, not required x402 fields. They prevent a valid payment requirement from being reused for the wrong input or after the buyer's freshness window.
The validator should then ask:
Does the requirement use a registered x402 version and payment scheme the client supports?
Does the network match an approved wallet and canonical network identifier?
Is the asset contract known, and were decimals resolved from trusted metadata?
Does the amount fit the transaction cap and remaining task budget?
Does
payTomatch the approved service identity or merchant record?Is the quote still fresh under local policy?
Did the price, recipient, scheme, or endpoint drift from discovery metadata beyond the allowed tolerance?
Is the request body exactly the one the agent evaluated?
A mismatch should not trigger a blind retry with payment. Small allowed drift can cause rescoring. A new recipient, unsupported asset, changed billing basis, or price above policy should return the candidate to approval or rejection.
Redirects deserve particular care. A redirect to another domain or route may represent another service, not the same purchase. The client should obtain and validate a new requirement rather than forwarding payment credentials automatically.
Filter Compatibility Before Estimating Value
Expected value is irrelevant when the service cannot produce a usable result. Cheap incompatibility is still wasted money.
Run hard filters first:
Capability fit: The advertised operation must match the task, and required input fields must be available. A semantic description is useful for search, but schema compatibility should decide whether the candidate can advance.
Output fit: The result type, data freshness, media type, precision, and size must work with the next step. If the agent needs structured records, a prose answer is not an equivalent substitute.
Payment fit: At least one quoted option must match an approved network, asset, payment scheme, wallet, and settlement path.
Policy fit: The service, recipient, action, and amount must fall within allowlists, per-payment limits, task budgets, and approval rules. A positive economic score never overrides a policy denial.
Operational fit: The endpoint must meet the task's deadline and support safe retry behavior. For state-changing or expensive calls, the agent also needs idempotency and a way to distinguish “payment pending” from “not paid.”
Minimum trust: Identity continuity, relevant delivery history, and reputation may determine whether the agent can pay automatically, needs approval, or must reject the candidate. Trust should adjust confidence and authorization tier, not be confused with the service's price.
Only candidates that pass these filters should consume model effort, quote requests, or wallet operations.
Decide Whether the Service Is Worth Buying
The cheapest compatible service is not necessarily the best purchase. An agent buys an expected contribution to a task, not an API call in isolation.
A simple decision model is:
Then compare that result with the best available fallback:
The fallback may be another paid service, a cached result, a slower internal tool, a human review, or abandoning a low-value subtask. This comparison prevents an agent from buying a positive-value service when an already available option is better.
The hard part is estimating P(useful result). Generic popularity is a weak prior. The most relevant evidence comes from the same service version, similar inputs, similar task class, and the agent's own accepted-delivery records. A service that performs well for translation may have no useful history for legal entity resolution.
For a new service, use a conservative prior and a low exposure limit. The agent can run a small paid sample, inspect the output, and update its estimate. It should not extrapolate one successful call into unlimited approval.
Not every task needs a monetary value. For compliance checks or safety-critical operations, policy may require a particular class of service regardless of a simple return calculation. In that case, the agent should rank qualified providers by cost and reliability inside the mandatory constraint, not invent a dollar value for the obligation.
Worked Example: Choosing a Paid Research Endpoint
Consider a hypothetical research agent that needs one current, structured record to finish a report. A useful result contributes an estimated $0.50 of workflow value. An internal cache is available as a fallback with an expected net value of $0.31.
Two discovered endpoints pass the schema, network, asset, and recipient filters. The agent probes each endpoint and receives a fresh quote.
Candidate | Useful-result probability | Live quote | Expected latency, failure, and risk cost | Expected net value |
|---|---|---|---|---|
Service A | 90% | $0.06 | $0.04 | $0.35 |
Service B | 68% | $0.02 | $0.05 | $0.27 |
The calculation is:
Service B is cheaper, but it loses to the free fallback. Service A exceeds the fallback by $0.04, so it is the better purchase if the configured decision margin is smaller than that difference.
Policy still has the final word. Suppose the task's automatic per-request cap is $0.08. Service A can proceed at $0.06. If its live 402 requirement changes to $0.09, the agent must not rely on the old catalog price. It should skip, request approval, or use the fallback according to policy.
The numbers are illustrative. A production agent should derive success probabilities and recovery costs from its own request, delivery, and acceptance history. The important pattern is that price is one term in a task-specific decision, not the ranking function by itself.
Metadata Drift Is the Normal Failure Mode
Service catalogs, manifests, wallets, and endpoints update on different schedules. A production agent should treat drift as routine rather than exceptional.
The catalog price is lower than the live requirement
Use the live requirement as the proposed price. Recompute value and policy. Record the drift so the catalog adapter can lower freshness confidence or request an update.
The billing unit changed
A move from “per request” to “per token” changes the product, even when the display amount looks smaller. Reject the quote until the agent can calculate a safe upper bound for the new unit.
The payment recipient changed
Do not treat this as ordinary price drift. Re-run identity and ownership checks or require approval. A correct amount sent to an unapproved recipient is still an unauthorized payment.
The endpoint redirects
Resolve the redirected endpoint as a new candidate. Fetch its descriptor and requirement without forwarding a signature or reusable payment payload.
The descriptor has no output schema
The agent cannot establish structural compatibility. It may reject the service, require a sandboxed sample, or lower the useful-result probability enough that the candidate no longer beats the fallback.
A maximum authorization looks like the final price
Budget against the maximum exposure. Track the amount actually settled separately. Otherwise the agent can approve several variable-price calls whose combined ceilings exceed the task budget.
Search ranking is mistaken for task fit
Catalog quality may reflect completeness, activity, or unique payers. Those signals help ranking but do not establish relevance to this input. Re-rank using local task outcomes after retrieval.
A timeout triggers another payment
Before retrying, check the prior payment and delivery state using an idempotency key, payment reference, or settlement status. “No response” is not proof that no payment occurred.
Compose Discovery, Payment, and Runtime as Separate Layers
No single protocol needs to own the whole purchasing loop. A modular architecture can use the strongest available component at each boundary:
The discovery adapters can ingest an approved service list, MCP tool manifests, A2A Agent Cards, ERC-8004 metadata, or an x402 catalog. The normalized catalog prevents the rest of the agent from depending on one provider's result shape. Every field should retain provenance and an observation time so conflicting metadata can be traced.
The quote probe calls the exact candidate route with the intended input and without payment. It translates the live payment requirement into the buyer's normalized quote, but it does not authorize spending. The policy and expected-value engine decides whether the quote can proceed, requires approval, should be skipped, or needs another discovery round.
GOAT Network's current agent stack illustrates how several of these layers can compose without becoming one monolith. Through AgentKit's ERC-8004 plugin, a developer can publish machine-readable registration metadata containing service endpoints, an x402Support indicator, activity state, and trust references. GOAT Flow provides HTTP-native payments using x402, while AgentKit supplies wallet actions, framework adapters, and runtime controls for execution.
Those components provide identity, payment, and action surfaces. They should not be misread as a universal service index or an automatic value model. An application still needs a catalog or indexer adapter, quote normalization, task-specific utility logic, and spending policy unless the selected infrastructure explicitly provides each function. Likewise, an endpoint advertised through ERC-8004 is not automatically present in a particular x402 catalog, and a catalog result is not automatically bound to an ERC-8004 identity.
This separation is useful. A team can change its discovery provider without changing wallet policy, add another payment rail without rebuilding service evaluation, or replace a ranking model while preserving audit records.
A Reference Discovery-to-Purchase Loop
The full implementation can be reduced to a deterministic sequence:
Convert the task into required capabilities, inputs, output constraints, deadline, and maximum acceptable cost.
Query approved discovery adapters and normalize every result with provenance and freshness.
Deduplicate candidates by stable service identity and endpoint ownership, not display name alone.
Apply capability, schema, protocol, network, asset, and minimum-trust filters.
Request a fresh quote from each remaining candidate using the intended request.
Validate the payment requirement and bind it to the request fingerprint.
Normalize the all-in cost and compare live terms with discovery metadata.
Estimate expected value against the best fallback using task-specific outcome history.
Apply budget, recipient, time, risk, and approval policies.
Return an explicit decision:
buy,request_approval,skip, orretry_discovery.If approved, sign only the selected requirement and send the request once under an idempotency key.
Reconcile payment, delivery, and acceptance before updating service history.
The policy result and the utility result should remain separate in logs. “Denied by policy” means the purchase was not permitted. “Skipped on value” means it was permitted but not worth making. Combining them into one rejection code makes later debugging and policy tuning unreliable.
The outcome ledger should also distinguish transport success from task success. A 200 response may satisfy the API contract while returning data that is stale, incomplete, or irrelevant. Only downstream acceptance can update the service's useful-result probability for that task class.
FAQ
How do AI agents discover paid services?
They can use administrator-approved lists, searchable catalogs, MCP tool manifests, A2A Agent Cards, agent registries such as ERC-8004, or direct endpoint configuration. A production system usually normalizes more than one source into a local service catalog.
Is an MCP tool definition enough to communicate price?
No. MCP defines callable tools with descriptions and input/output schemas, but its core tool definition does not provide a universal pricing contract. A paid tool needs a separate payment extension, catalog record, or live protocol such as x402 to communicate payment terms.
Does x402 provide service discovery?
x402 supports discovery through extension and ecosystem implementations such as the Bazaar catalog, while the core HTTP payment handshake communicates terms for an endpoint already being called. Not every x402 service is necessarily indexed by one catalog, so agents may need multiple discovery adapters.
Can an agent trust the price shown in a catalog?
It can use the catalog price to filter and rank candidates, but it should obtain a fresh requirement from the endpoint before signing. The live quote must be rechecked against budget, recipient, network, asset, scheme, and local price-drift rules.
How should an agent compare prices in different assets or units?
First normalize token decimals and payment assets using trusted metadata. Then convert billing units into the expected cost for the intended request, including maximum exposure for variable pricing and network or retry costs when applicable. Comparisons should use a common internal cost basis with a timestamped conversion source.
What happens when the live quote differs from the catalog?
The agent should use the live quote as the proposed payment, rescore expected value, and re-run policy. A change in recipient, scheme, billing unit, or unsupported asset should trigger rejection or approval rather than ordinary repricing.
What determines whether a paid service is worth buying?
The decision should compare the service's expected task contribution with its all-in cost, latency, failure recovery, risk, and the value of the best fallback. The payment proceeds only when that expected value is high enough and the principal's spending policy allows it.
Keep the Descriptor Stable and the Quote Disposable
Machine-readable commerce works when an agent knows which information can be reused and which must be refreshed.
The service descriptor should remain stable enough for discovery, deduplication, schema matching, and identity checks. The payment quote should be short-lived, request-bound, and discarded when material terms change. The purchase decision should be recomputed from the current task, current policy, and current fallback. The outcome record should persist so future decisions rely on observed usefulness rather than advertising alone.
That gives each layer one job: descriptors help agents find services, payment requirements tell them what a request costs, policy defines what they may buy, and outcome history helps determine what is worth buying again.
