x402 Bazaar: cómo los agentes encuentran y pagan APIs solos

x402 responde "cómo paga un agente una API". El Bazaar responde la pregunta anterior: qué API, a qué precio, con qué input schema — y deja que el agente lo averigüe en runtime en vez de en build time.

Llevamos una racha de posts sobre el lado del pago del comercio entre agentes. x402 convierte un HTTP 402 en un pago liquidable. EIP-3009 es el primitivo gasless que va debajo. La extensión A2A x402 deja que un agente le cobre a otro. Todo eso asume que el agente ya sabe a dónde ir. Ese supuesto es el último apoyo que queda en el comercio "autónomo": un humano todavía tenía que elegir el endpoint, conseguir la key y cablearla.

El Bazaar es el intento de Coinbase de quitar ese apoyo. Es la capa de discovery de x402 — un catálogo de endpoints con precio que los agentes pueden buscar, tasar y llamar sin ninguna integración precocida. Este post lo lee de punta a punta desde la documentación de CDP y el SDK de referencia.

Qué es el Bazaar en realidad

Piensa en páginas amarillas para la web agéntica, hechas para máquinas y no para humanos. El Bazaar indexa endpoints con x402 junto con su metadata de pago — network, asset, precio, destinatario — y, donde el seller lo declara, el input y output schema del endpoint. Un agente que puede consultar ese índice pasa de "necesito datos de clima" a una respuesta paga y estructurada sin que un desarrollador toque el code path.

El índice lo puebla y lo sirve el CDP Facilitator. Esto importa para el modelo mental: en x402 el facilitator es la parte que corre /verify y /settle contra la cadena por cuenta de un resource server. El Bazaar va montado sobre ese mismo facilitator. Como el facilitator ya ve cada pago, está bien ubicado para catalogar cada endpoint que liquida — el discovery cae como efecto secundario del settlement.

Sin paso de registro: te indexan por cobrar

La decisión de diseño que hace interesante al Bazaar es que no hay formulario de alta. No registras un endpoint. El CDP Facilitator cataloga tu servicio la primera vez que liquida un pago para ese endpoint.

La consecuencia es sutil y vale decirla con claridad: un endpoint con precio recién creado es invisible hasta que toma su primer pago real. Hay un paso de bootstrap donde tú (o un agente de prueba) le pagas a tu propio endpoint una vez para sembrarlo en el catálogo. Después de eso el listing persiste — aunque los endpoints sin actividad en los últimos 30 días se descartan del catálogo, así que un servicio que deja de usarse desaparece en silencio.

El facilitator señala si aceptó tu metadata de discovery a través de un header EXTENSION-RESPONSES en la respuesta de verify/settle, con un estado de processing o rejected. Ese es el diagnóstico al que recurres cuando un endpoint liquida pero nunca aparece. Es también, al momento de escribir, un punto sensible conocido — el issue 2112 en el repo de x402 reporta que el facilitator de CDP no emite el header en absoluto, dejando a sellers con pagos liquidados y sin forma de saber por qué su servicio falta en el índice. Léelo como señal de madurez, no como impedimento: la extensión está codificada pero la plomería operativa todavía se está endureciendo.

Tres superficies HTTP, un índice

Todo cuelga del base de CDP https://api.cdp.coinbase.com/platform/v2/x402. Tres superficies de lectura exponen el mismo catálogo para distintos patrones de acceso.

Cada listing lleva la misma forma central: resource (la URL del endpoint), type (hoy "http"), x402Version, un array accepts de payment requirements — scheme, network, amount, asset, payTo — un timestamp lastUpdated y metadata opcional con la descripción y los schemas. El array accepts es el campo que carga el peso: es el mismo PaymentRequirements que el agente va a devolver dentro de su pago x402, así que discovery y pago comparten un vocabulario.

El servidor MCP de discovery

La cuarta superficie no tiene forma HTTP para nada. En /discovery/mcp el Bazaar expone un servidor MCP, para que un agente pueda tratar discovery-y-pago como tool calls comunes. Ofrece dos tools:

• search_resources — discovery semántico sobre el índice, devolviendo descripciones, pricing y schemas ordenados por relevancia. La misma superficie de search, envuelta como tool.
• proxy_tool_call — invoca un recurso descubierto por nombre y argumentos. Este es el pago: el agente no solo se entera de que el endpoint existe, lo llama a través del proxy.

El wrapper de cliente MCP de x402 cierra el loop del pago. Cuando proxy_tool_call topa con un 402, el wrapper construye el payment payload, lo adjunta al campo _meta del request MCP y reintenta de forma transparente — el tool call del agente tiene éxito sin que el modelo jamás vea un error de pago.

const paymentClient = new CdpX402Client();
const client = createX402MCPClient(mcpClient, paymentClient, { autoPayment: true });

// search_resources lo encuentra, proxy_tool_call lo llama,
// el wrapper paga el 402 y reintenta — un tool call al modelo.

Es la misma disciplina de "las llaves fuera del modelo" que marcamos en el post de A2A x402, aplicada al discovery. El modelo razona sobre qué tool llamar; el wrapper maneja la firma y el reintento.

Declarar un recurso como seller

Hacer un endpoint descubrible son tres piezas en el SDK de referencia (@x402/extensions/bazaar, con un equivalente en Go en github.com/coinbase/x402/go/extensions/bazaar que cubre v1 y v2). Envuelves el cliente del facilitator con withBazaar(), registras bazaarResourceServerExtension y adjuntas declareDiscoveryExtension() a cada route que quieras listar.

import { declareDiscoveryExtension } from '@x402/extensions/bazaar';

"GET /weather": {
  accepts: [{ scheme: "exact", price: "$0.001", network: "eip155:8453", payTo: "0xYourAddress" }],
  description: "Get real-time weather data",
  mimeType: "application/json",
  extensions: {
    ...declareDiscoveryExtension({
      input: { city: "San Francisco" },
      inputSchema: {
        properties: { city: { type: "string", description: "City name" } },
        required: ["city"],
      },
    }),
  },
}

La validación es estricta a la entrada. El input declarado debe pasar validación JSON Schema contra el schema que aportas, y las descripciones tienen tope de 500 caracteres. Es deliberado: todo el valor de un índice de discovery es que una máquina pueda confiar en el schema que lee, así que el facilitator rechaza declaraciones que mienten sobre su propia forma. Del lado del facilitator, helpers como extractDiscoveryInfo() (Go: ExtractDiscoveredResourceFromPaymentPayload, ValidateAndExtract) sacan esa metadata del pago liquidado.

Consultarlo como buyer

El lado del buyer es más chico. Envuelves el cliente del facilitator con withBazaar() y llamas listResources a través de la extensión de discovery. Filtrar por precio es trabajo de array puro, porque accepts.amount está ahí mismo en el listing.

import { HTTPFacilitatorClient } from '@x402/core/http';
import { withBazaar } from '@x402/extensions/bazaar';

const facilitator = withBazaar(
  new HTTPFacilitatorClient({ url: "https://api.cdp.coinbase.com/platform/v2/x402" })
);

const discovery = await facilitator.extensions.discovery.listResources({ type: "http", limit: 20 });

// Solo endpoints bajo $0.10 (amount va en unidades atomicas)
const affordable = discovery.items.filter((i) =>
  i.accepts.some((req) => Number(req.amount) < 100000)
);

Fíjate en el segundo argumento de listResources: type es un filtro. type: "http" devuelve endpoints HTTP; type: "mcp" devuelve tools MCP descubribles. El catálogo no es solo endpoints REST — es el sustrato para que un agente encuentre también las tools de otros agentes.

Confianza, ranking y dónde se raja

Discovery sin confianza es un imán de spam. El Bazaar se apoya en lo único que tiene que un registro común no: el historial de settlement. El ranking de search mezcla relevancia de recuperación con señales de calidad objetivas — alcance de buyers, volumen de transacciones, recencia, calidad de metadata — y esas métricas se recomputan en un ciclo de seis horas. Un endpoint que muchos agentes distintos realmente pagan rankea por encima de uno que solo existe. El pago on-chain se vuelve una señal de reputación resistente a Sybil, porque falsearlo cuesta USDC real.

Esa es una propiedad genuinamente linda, y es también donde tiene que entrar la honestidad. El ranking es de CDP, computado dentro del facilitator de CDP, sobre pagos liquidados por CDP. El Bazaar hoy es un producto de Coinbase, no una capa de protocolo neutral. El hueco de EXTENSION-RESPONSES en el issue 2112 recuerda que la superficie operativa es joven. Y el corte de actividad a 30 días más el lag de ranking de seis horas hacen que el catálogo sea una vista móvil y opinada, no un ledger duradero. Para una capa de confianza de grado settlement quieres algo más cerca del registro de reputación on-chain de ERC-8004. El Bazaar es la versión rápida, útil y centralizada de esa idea — excelente para encontrar endpoints hoy, no la cosa a la que anclas identidad de largo plazo.

Qué significa para LLM4Agents

Nuestro stack ya tiene los dos vecinos del discovery. El gateway es una superficie con precio x402, compatible con OpenAI — un endpoint pagable. Nuestro servidor MCP expone tools que un agente puede llamar. El Bazaar se sienta exactamente entre ambos: es cómo un agente que nunca oyó de nosotros podría descubrir el gateway, leer su precio y schema, y empezar a pagar — sin onboarding, sin emisión de key, sin humano en el loop.

Ese es un canal de distribución que no controlamos pero en el que deberíamos estar presentes. Si los buyers autónomos arrancan cada vez más desde un query de discovery en vez de un base URL hardcodeado, entonces no estar en el índice significa no ser alcanzable por la clase de cliente que más rápido crece. La contracara es un threat model: una capa de discovery que rankea por volumen de settlement premia a quien más liquida a través de un solo facilitator, lo cual es una presión centralizadora suave hacia CDP. LLM4Agents liquida a través de múltiples cadenas y rails; debemos asegurarnos de que nuestra descubribilidad nunca dependa de rutear todo el settlement por el facilitator de una sola parte.

Cómo mantenerse en la frontera

Movidas concretas, en orden.

Primero, hacerse indexar. Adjuntar declareDiscoveryExtension() a las routes con precio del gateway y a las tools MCP, sembrar cada una con un settlement real, y confirmar que el estado de EXTENSION-RESPONSES vuelve como processing. Si falla en silencio — el caso del issue 2112 — reportarlo y guardar los recibos, porque estar en el catálogo es lo mínimo.

Segundo, publicar schemas honestos. El ranking premia la calidad de metadata y el validador rechaza mentiras. Declarar los input y output schema reales para cada route descubrible para que un agente que nos encuentre nos llame bien al primer intento. Un schema limpio es una optimización de conversión para buyers máquina.

Tercero, correr un cliente Bazaar del lado buyer, no solo un listing de seller. El mismo índice de discovery deja que nuestros propios agentes encuentren tools de terceros para componer. Cablear withBazaar() y proxy_tool_call en el runtime del agente para que una flota pueda descubrir-y-pagar capacidades que no hospedamos, con precio por llamada en stablecoins.

Cuarto, no dejar que el discovery se vuelva lock-in. Tratar al Bazaar de CDP como un índice entre varios. Mantener nuestro propio catálogo canónico y auto-hospedado de lo que vendemos, espejarlo en CDP por alcance, y seguir ERC-8004 para que cuando madure una capa de discovery-y-reputación neutral y on-chain, nuestra identidad e historial porten hacia ella en vez de quedar atrapados en el ranking de un solo facilitator.