Invoket

Machine-readable discovery: x402, the CDP Bazaar and MCP

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.

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 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 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 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 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).

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), 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 → /openapi.json → /catalog to enumerate every paid endpoint and its rails.
  3. By LLM site map. 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. Once an endpoint is found, the request → 402 → sign → replay cycle is the same for every channel; the runnable version is in the Quickstart, and the accepted assets and networks are in Payments and rails.

Public explorers

Beyond the canonical channels, third-party explorers index x402 resources for human and machine browsing — for example x402scan, 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, 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