x402 Bazaar Guide: Discover and Validate Paid Resources

Search for the result your agent needs

Suppose a finance research agent needs a company report containing a legal-entity identifier and a source date. It should search for that task rather than merely choosing the first endpoint mentioning finance. The relevant question is whether the service produces the particular data the assessment needs.

The official Bazaar extension reference describes machine-readable resource discovery and metadata for HTTP endpoints and MCP tools. Facilitators can implement a discovery layer, so verify which catalog and implementation your client is querying. A result from one discovery service should not be described as an exhaustive view of every payable service. [1]

Keep the discovered resource and source timestamp in your application record. A later payment decision should be based on current terms, while the stored discovery information explains how the agent found the service. This distinction is useful when listings change or an endpoint stops matching its description.

Read the resource and invocation information

For an HTTP resource, identify the actual endpoint and documented method. Read the required input and expected output metadata. The company-report example needs a specific identifier input; a listing with a broad company intelligence description may still be unsuitable if its schema expects a different kind of query.

For an MCP tool, the tool identity and input schema matter alongside the resource information. A server can expose more than one tool. Do not assume that a server address alone identifies the paid operation the agent intends to call. The official extension reference describes these distinct resource types. [1]

The annotated record below separates an observed public listing from the missing schema and payment evidence. An actual parser must still use the current schema for the selected discovery implementation and protocol revision. A directory description alone cannot establish the complete response contract.

Missing metadata should become an explicit open question. The agent can inspect official seller documentation or choose another resource. It should not invent required arguments, expected results or commercial terms to make a listing appear usable.

Inspect payment terms without assuming their units

A discovery entry can advertise accepted payment options. Check the scheme, network, asset, amount and recipient for the option your client supports. Do not add two amounts in different assets or infer a dollar price from a raw string without understanding the denomination.

For the report, define an illustrative maximum of $0.10 only as a planning example. The current seller offer supplies the real payment terms. The agent's policy must evaluate the actual terms rather than comparing a guessed display value with the maximum.

Discovery metadata and a seller response may differ because time has passed or the offer changed. Decide which evidence your application uses for the final purchase and reevaluate permission when material terms change. A previously affordable listing is not continuing authority for a later, different offer.

Also check compatibility at the interface level. A wallet may hold the advertised asset while the chosen client lacks the supported scheme or transport. Resource discovery reduces the work of finding candidates; it does not remove implementation checks.

An unpaid inspection of a published resource

On 8 October 2026 we inspected Coinbase-operated Agentic Market’s public BlockRun.AI listing without submitting a payment or credential. It lists a GET /api/v1/defillama/chains resource described as chain-level total value locked data. That is a real published discovery candidate for a finance agent, but its description does not establish that it returns our requested legal-entity report. [3]

The inspection established the listed provider, operation path, method and seller description. It did not establish the complete input/output schema, current signed payment requirements, successful execution or data quality. Our decision is to reject this candidate for the company-report task and keep those payment and response fields unverified. The annotated card distinguishes the published facts from the missing evidence.

The public Market Research bundle also linked to a finance service page that returned 404 during our inspection. That failed link is a useful result: a bundle label cannot prove an individual service is accessible. Neither check was a paid call, and neither supplies a payment-success rate. The next step for a suitable candidate is to inspect the seller’s current documentation and unpaid challenge through a client that cannot sign automatically. [4]

Validate without describing a probe as a purchase

You can inspect public documentation and relevant unpaid responses before a paid attempt. Keep that activity separate from a completed purchase. A resource returning a payment challenge demonstrates a response at that moment, not successful settlement or delivery.

The local validation checklist helps record what you actually established. It does not call remote endpoints or spend money. A reader can mark the inspected terms, required input, expected output and recovery route, then export those notes as an integration aid.

If you implement a live preflight elsewhere, state whether it submits payment, signs a credential or only inspects metadata. Automatic payment handling can turn an apparently ordinary resource request into a financial action. The tool boundary and user authority need to make that behavior clear.

Avoid using a successful schema check as a report-quality rating. The service may return structurally valid data that does not support the procurement decision. Define substantive acceptance conditions before paying and check them afterward.

Check seller discovery claims separately

Coinbase's current seller guide describes publishing discovery metadata for an x402 endpoint. That is a seller integration path, not evidence that a particular listing is universally visible or highly ranked. Verify the actual cataloging outcome using the implementation's documented evidence. [2]

If you operate the company-report API, make the description, input and output useful to a buyer. Explain the identifier format and returned source date. A generic sentence saying powered by AI does not tell an agent how to construct a valid request or recognize a delivered report.

Keep prices and payment options aligned with the resource configuration. A stale public description can mislead buyers even if the server's current challenge is correct. Assign ownership of those updates and review them when the service changes.

Do not fabricate listing counts, traffic or conversion statistics to justify discovery inclusion. The operational objective is that a suitable buyer can find, understand and use the resource through the documented route.

Prepare one bounded resource purchase

Choose a candidate whose input, output and payment option match the task. Record the current offer, obtain appropriate authority and submit through the configured payment client. Then validate that the report identifies the intended company and contains the required information.

If payment is confirmed but the report is missing, inspect the existing purchase before another paid attempt. Discovery does not supply a universal result-recovery or refund mechanism. The seller needs a documented route, and your application needs to know how to use it.

For an uncertain outcome, keep the attempt unresolved and preserve references. Do not count a request as a successful purchase merely because the agent found a payable resource. The completed evidence trail includes the authorized terms, financial outcome and delivered result.

The next guide depends on your role. Buyers should read the x402 exchange and wallet guides. Sellers should read the API acceptance guide and current discovery documentation. Developers exposing MCP tools should inspect that payment boundary separately. Each route builds on discovery while preserving its own responsibility for authority and delivery.