# How does an agent find a paid API with no human in the loop? > How an autonomous agent finds a paid API with no human in the loop — semantic search over the CDP x402 Bazaar, paid tools exposed through MCP, and per-origin manifests. Published 2026-06-28 · Updated 2026-08-15 · HTML version: https://invoket.com/blog/machine-readable-discovery-x402-bazaar-mcp --- An autonomous agent that needs a capability mid-task cannot stop to read a vendor's landing page. It has to **find** a paid endpoint by describing the problem, learn what the call costs, and call it — all in code. Three machine-readable channels make that possible: the **CDP x402 Bazaar**, a registry an agent searches by intent; the **Model Context Protocol (MCP)**, which surfaces that registry as a tool a model calls natively; and each origin's own **manifest and catalog**, the authoritative description of what it sells. This article maps those channels and how they fit together, with sources. It is the discovery half of the loop whose payment mechanics are covered in [What happens between a 402 challenge and the paid response](/blog/how-an-agent-discovers-and-buys-a-paid-api). ## The problem: discovery without a human API keys, dashboards and docs portals assume a developer who reads, decides and integrates once. An agent has none of that patience. For it, discovery must be **queryable by intent** ("screen an IBAN", "validate a phone number") rather than by vendor name, **structured** enough to build a valid request without prose parsing, and **callable** from inside the agent's own runtime. The three surfaces below each cover one of those needs. ## 1. The CDP x402 Bazaar: search a registry by intent The [x402](https://github.com/coinbase/x402) standard settles payments per HTTP request, but a payment protocol alone does not tell an agent *where* to pay. That is the job of a **discovery layer**. The [CDP x402 Bazaar](https://docs.cdp.coinbase.com/x402/bazaar) is Coinbase's index of paid x402 resources: any resource that settles through the CDP facilitator is indexed there automatically, so an agent can find it without prior knowledge of the vendor. The Bazaar exposes two HTTP shapes for finding resources: - **Semantic search** — `GET /v2/x402/discovery/search`: a query plus filters, returning relevance-ranked resources. This is the "by intent" path. - **Paginated catalog** — `GET /v2/x402/discovery/resources`: inventory-style browsing with `limit`/`offset`, for crawling the whole index. Each returned resource carries the description, price, and input/output schema an agent needs to evaluate and build a call — not just a URL. Crucially, **settlement is what populates and ranks the index**: a resource appears because real payments flow through the facilitator, which makes Bazaar ranking resistant to listings that never transact. ## 2. MCP: the registry as a tool the model calls itself A registry an agent has to learn to call by hand is still friction. The [Model Context Protocol](https://modelcontextprotocol.io) removes it. MCP is the open standard for connecting LLM applications to external context and capabilities, built around a few primitives — **tools** (capabilities the model invokes), **resources** (read-only data the application supplies), and **prompts** — each discoverable through standard `list` operations so a client learns what a server offers at connect time ([MCP specification](https://spec.modelcontextprotocol.io/)). The Bazaar speaks MCP directly. The CDP facilitator exposes an MCP endpoint at `GET /v2/x402/discovery/mcp`, and the official x402 MCP server provides a **`search_resources`** tool over the same index. Because `search_resources` is an MCP *tool*, it is **model-controlled**: a runtime like Claude, Cursor or Windsurf can call it as part of normal reasoning. The agent issues a natural-language query, gets back matching paid endpoints with their schemas and prices, and proceeds — no bespoke integration with any single API. The payment itself stays inside the same channel: an x402-aware MCP client that hits a payment-required response signs and replays it automatically, so discovery and settlement happen without leaving the tool call. ## 3. Per-origin surfaces: the authoritative description A registry tells an agent *that* a relevant endpoint exists; the **origin** tells it *exactly* how to call and pay. Following the well-known URI convention ([RFC 8615](https://www.rfc-editor.org/rfc/rfc8615.html)), an x402 origin publishes a small discovery cascade that an agent can read directly: - **`/.well-known/x402`** — the manifest: where the gateway lives and where to find the catalog, the bootstrap entry point for a crawler. - **`/openapi.json`** — the OpenAPI description: methods, parameters and response shapes, so the agent can construct a valid request. - **`/catalog`** — the living catalog in **Bazaar x402 format**: for each resource, its method, its price and its accepted rails. The catalog is the **source of truth**. Where the registry's cached entry and the origin's catalog disagree, the catalog wins — which is why an article like this never pins a price or a rail: those are served live, not frozen into prose. ## How the channels compose, against Invoket Invoket settles through the CDP facilitator, so it is reachable through all three channels at once: 1. **By intent (Bazaar / MCP).** An agent calls `search_resources` with a query like `verify payee` or `IBAN sanctions screening`; Invoket's matching endpoints come back ranked, with schemas and prices. No prior knowledge of Invoket required. 2. **By crawling the origin.** An agent reads [`/.well-known/x402`](https://api.invoket.com/.well-known/x402) → `/openapi.json` → [`/catalog`](https://api.invoket.com/catalog) to enumerate every paid endpoint and its rails. 3. **By LLM site map.** [`invoket.com/llms.txt`](https://invoket.com/llms.txt) gives a model a concise map of the human-readable surfaces, including this blog. These are complementary, not redundant: the Bazaar makes Invoket *findable* by an agent that has never heard of it; the origin surfaces make it *callable* with exact, current terms. The full path — and the discovery channels in operational detail — is documented in [For agents](/docs/for-agents). Once an endpoint is found, the request → `402` → sign → replay cycle is the same for every channel; the runnable version is in the [Quickstart](/docs/quickstart), and the accepted assets and networks are in [Payments and rails](/docs/payments-and-rails). ## Public explorers Beyond the canonical channels, third-party explorers index x402 resources for human and machine browsing — for example [x402scan](https://x402scan.com), a public explorer of x402 activity. These are useful for observability, but the authoritative terms of a call always come from the origin's catalog, never from a mirror. ## What discovery does not decide Discovery answers *which endpoint and where* — not *how much* or *which rail*. The price, the atomic amount, the `payTo` recipient and any signature are **authority data**: they live behind the live `402` challenge and the [catalog](https://api.invoket.com/catalog), and an agent reads them at call time. A discovery surface that froze those values would be wrong the moment they changed. The registry helps an agent *find* the call; the gateway settles it. ## Sources - CDP x402 Bazaar (discovery layer, search/resources/MCP endpoints) — [Coinbase Developer Platform: x402 Bazaar](https://docs.cdp.coinbase.com/x402/bazaar), [CDP x402 overview](https://docs.cdp.coinbase.com/x402/welcome). - x402 protocol — [coinbase/x402 (GitHub)](https://github.com/coinbase/x402), [x402.org](https://www.x402.org/). - Model Context Protocol (tools, resources, discovery) — [modelcontextprotocol.io](https://modelcontextprotocol.io), [MCP specification](https://spec.modelcontextprotocol.io/). - Well-known URIs convention — [RFC 8615](https://www.rfc-editor.org/rfc/rfc8615.html). - Public explorer — [x402scan](https://x402scan.com).