Preguntas frecuentes

Respuestas breves a las preguntas más habituales sobre Burnbound. Cada respuesta enlaza con la página que tiene los detalles.

¿Qué es x402?

x402 es un protocolo abierto para pagar peticiones HTTP. Una API de pago responde 402 Payment Required con un precio; el cliente firma un pago en stablecoin y repite la petición con él; el vendedor liquida el pago y sirve la respuesta. Burnbound admite x402 v2 con el esquema exact en USDC.

¿Cómo limito lo que puede gastar mi agente de IA?

Dale al agente una política de Burnbound y deja que pague solo a través de Burnbound. Tú fijas los hosts a los que puede pagar, un máximo por pago, un tope diario y, si quieres, un umbral a partir del cual tiene que aprobar una persona. Fijes lo que fijes, el primer pago a una dirección de cobro a la que tu organización no ha pagado antes espera a una persona, y lo mismo ocurre con un pago cuyo 402 parece dar instrucciones al agente. El agente paga APIs x402 con la herramienta fetch_paid del servidor MCP de Burnbound, y cualquier pago fuera de esas reglas se deniega antes de firmarse. Empieza por los primeros pasos; How to limit an AI agent's spending (en inglés) explica cada límite.

¿Qué agentes y clientes MCP son compatibles?

Cualquier cliente MCP que pueda ejecutar un servidor stdio: Claude Code, Cursor y otros. El servidor es el paquete npm @burnbound/mcp y se ejecuta con npx -y @burnbound/mcp@latest. Las integraciones (en inglés) muestran la configuración para Claude Code, Cursor, Claude Desktop, el Vercel AI SDK, LangChain.js y Mastra. Existe un SDK de JavaScript, pero todavía no está publicado; consulta SDK.

¿Con qué redes y tokens puede pagar mi agente?

USDC en Base, o en Base Sepolia para pruebas. Los agentes nuevos pagan en Base mainnet (eip155:8453). Puedes pasar un agente a Base Sepolia (eip155:84532) al crearlo en el onboarding, o más tarde en su pestaña Red del panel. La política deniega cualquier otra red (network_not_allowed) o activo (asset_not_allowed). Consulta Conceptos.

¿Cómo pruebo sin dinero real?

Pon la red del agente en Base Sepolia, recarga su cartera con USDC de prueba del faucet de Circle y paga una API x402 que cobre en Base Sepolia. El flujo es el mismo que en Base: se aplican los topes, las aprobaciones y la auditoría. Cuando termines, vuelve a poner el agente en Base y recarga la cartera con USDC real en Base. Si el agente y el vendedor están en redes distintas, Burnbound deniega el pago con network_not_allowed antes de firmar nada.

¿Necesito ETH en la cartera?

No. Los pagos x402 son autorizaciones de transferencia de USDC (EIP-3009) que el facilitador del vendedor envía on-chain, así que es el facilitador quien paga el gas. Tu cartera solo necesita USDC.

¿Guarda Burnbound mis claves privadas o mi dinero?

No. Burnbound nunca guarda la clave privada de una cartera ni custodia fondos: los pagos van de tu cartera al vendedor. Con Coinbase CDP, Burnbound guarda cifradas tus credenciales de la API de CDP para poder pedir firmas de los pagos que tu política permite. Con la firma en el cliente, solo conoce la dirección de tu cartera. Consulta Seguridad y modelo de confianza.

¿Qué modo de firma debería elegir?

Elige Coinbase CDP si tu agente puede ejecutar comandos de shell o si necesitas un control que no dependa de la cooperación del agente: el agente nunca tiene nada que pueda firmar. Elige la firma en el cliente si quieres la clave en tu propia máquina y aceptas que un agente con acceso a la shell podría saltarse la política. Consulta Conceptos.

¿Puede mi agente subirse sus propios límites?

No. Una clave de agente puede leer su presupuesto y sus pagos, pedir autorización para un pago y consultar sus aprobaciones, pero no puede ampliar su política, aprobar un pago ni crear claves. Esas acciones requieren una persona con sesión iniciada en el panel. El único cambio que puede hacer un agente es uno más estricto: cuando el usuario se lo pide en el chat, propose_rule añade una regla que restringe más al agente y caduca sola.

¿Cómo doy a varios agentes un presupuesto compartido?

Dale a cada agente (o subagente) su propio agente y su propia clave de Burnbound, ponlos en un subequipo desde Subequipos en el panel y añade una regla de subequipo, por ejemplo un tope mensual para el subequipo. Cada agente conserva sus propios topes y, entre todos, nunca gastan más que el tope del subequipo, aunque paguen a la vez desde máquinas distintas. Consulta ¿Cómo funcionan los subequipos?.

¿Puedo añadir mis propias reglas de gasto?

Sí. Además de los topes, cada agente puede tener hasta 50 reglas propias: denegar algunos pagos, retenerlos para aprobación, ponerles un tope por día, semana o mes, o solo registrarlos. Parte de una plantilla («Tope semanal», «Tope por host», «Aprobación para un payee nuevo») y prueba una regla en modo observación antes de aplicarla. Consulta ¿Qué son las reglas propias?.

¿Qué pasa si Burnbound no está disponible?

Tu agente no puede pagar y no se cobra nada. fetch_paid falla en cerrado: si no puede cargar los hosts permitidos del agente u obtener una decisión de Burnbound, devuelve un error (control_plane_unavailable, api_unavailable, api_unreachable o api_timeout) y no paga nada.

¿Qué pasa si un pago no se completa?

fetch_paid devuelve paid solo cuando el vendedor ha servido la petición pagada (un 2xx). Cualquier otra cosa es un error de la herramienta con un código, y fetch_paid nunca vuelve a firmar el pago por su cuenta:

• insufficient_funds: la cartera que paga no tiene suficiente USDC en la red del pago, por ejemplo Wallet 0x1234…5678 has 0.00 USDC on Base; this payment needs 0.01 USDC. Burnbound lo comprueba antes de firmar nada, así que no se pagó nada. Añade USDC a esa cartera en esa red y vuelve a intentarlo. La comprobación es una cortesía, no una garantía: el saldo puede cambiar antes de que el vendedor liquide y, si Burnbound no puede conectar con la red, se salta la comprobación.
• payment_rejected_by_seller: el pago se firmó y se envió, pero el vendedor lo rechazó (a menudo con otro 402) y no sirvió la respuesta. El motivo del vendedor, cuando lo da, llega en sellerReason, marcado como texto no fiable. Una causa habitual es una cartera sin USDC suficiente; otra, un vendedor cuyo facilitador está fallando. Comprueba la causa antes de reintentar.
• payment_not_completed: el vendedor respondió a la petición pagada con otra cosa, como una redirección o un error del servidor. El pago aún puede liquidarse; consulta list_payments antes de reintentar.
• payment_outcome_unknown: se perdió la respuesta del vendedor. Consulta list_payments para ver si el pago se liquidó.

En los tres últimos casos, el error lleva el intentId y la idempotencyKey, y Burnbound registra el recibo fallido con el estado y el motivo del vendedor. Reintentar fetch_paid con la misma idempotencyKey nunca cobra dos veces. Consulta Herramientas MCP.

Para saber por qué no se puede pagar a un vendedor, sin pagar, el agente puede llamar a diagnose_payment, o puedes ejecutar npx -y @burnbound/mcp@latest doctor <url> en una terminal, sin cuenta. Consulta Herramientas MCP.

¿Cobra Burnbound una comisión por los pagos?

No. Burnbound no se queda con un porcentaje de lo que pagan tus agentes; los pagos van íntegros de tu cartera al vendedor. Lo que pagas es el plan.

La bandeja de aprobaciones, los topes, los hosts permitidos y las reglas de la política están en todos los planes. Stripe gestiona la facturación.

¿Cómo impido que un agente pague?

Revoca su clave en el panel. A partir de ahí, el servidor MCP recibe unauthorized en cada llamada y no puede autorizar pagos. Para pararlo de inmediato sin revocar la clave, quita sus hosts permitidos o baja su tope diario: una lista de hosts vacía no permite ningún pago.

¿Hay documentación para LLM?

Sí. /llms.txt recoge todas las páginas de la documentación con una descripción de una línea, y /llms-full.txt contiene toda la documentación en un único archivo Markdown de texto plano (en inglés).