Monetiza tu servidor MCP en 10 minutos.
Deja que los agentes de IA paguen tu servidor MCP por llamada, en USDC, con webhooks firmados y registros de auditoría. Compatible con x402. Middleware de inserción.
Construiste un servidor MCP. Miles de clientes lo están utilizando de forma gratuita.
Enviaste tu servidor MCP porque los clientes Claude Desktop, Cursor y Cline necesitaban la capacidad. La noticia se difundió. Ahora estás sirviendo miles de invocaciones de herramientas pagadas por día de agentes de IA que nunca has conocido. Tu factura de salida es real. Tu clave API para el servicio subyacente es real. Tu tiempo de mantenimiento es real. Los ingresos son cero.
Tienes tres opciones. Mantenlo gratis y quema dinero en infraestructura. Colócalo detrás de claves API manuales (y pierde el 95% del tráfico de agentes por la fricción de los formularios de registro). O agrega una capa de pago que los agentes de IA puedan completar - que es exactamente para lo que se construyó 402 Payment Required + USDC.
Blockchain0x es la opción tres. Tu servidor MCP apunta a nuestra API. Cuando un cliente de IA llama a una herramienta de pago, la respuesta es 402 con una URL de pago alojada. El cliente (o su supervisor humano) paga en USDC. Tu webhook se activa. La siguiente llamada de ese cliente tiene éxito. Toda la forma se llama x402, y es el protocolo que Coinbase publicó para este patrón exacto.
Cómo 402 Payment Required se convierte en un checkout programático.
El código de estado HTTP 402 ha existido desde que se escribió la especificación por primera vez, pero nunca tuvo una implementación estándar. El protocolo x402 de Coinbase finalmente le da uno. La forma es simple: tu herramienta devuelve un desafío 402 (un cuerpo JSON estructurado que describe cómo pagar); el cliente paga y reintenta; la llamada tiene éxito. requirePayment de @blockchain0x/mcp construye ese cuerpo de desafío para ti.
{
"error": "payment_required",
"amountUsdc": "0.02",
"payTo": "0xYourMcpAgentAddress",
"hostedUrl": "https://pay.blockchain0x.com/checkout/docs-search",
"network": "mainnet",
"description": "docs search"
}Los cuatro estados
- Llamada no pagada: El cliente de IA invoca una herramienta pagada. Tu manejador verifica tu propio estado de pago, encuentra que el pagador no está marcado como pagado y devuelve el cuerpo del desafío 402 de requirePayment como un error de herramienta.
- Pago: El cliente sigue el hostedUrl al checkout alojado y completa la transferencia de USDC en Base (ya sea programáticamente a través de una billetera compatible con x402 o manualmente a través de un código QR).
- Webhook: Blockchain0x envía payment.received a tu endpoint dentro de segundos después de la confirmación de la cadena. Lo verificas con webhooks.verify y registras al pagador como pagado en tu propia tienda.
- Reintentar: El cliente reintenta la llamada a la herramienta MCP original. Tu manejador ahora ve al pagador marcado como pagado, ejecuta la herramienta y devuelve el resultado real.
Cada pago se registra en tu panel de Blockchain0x, y cada webhook payment.received llega a tus propios registros. Debido a que posees el estado pagado y el manejador de webhook, los análisis de ingresos por herramienta y por pagador se derivan de los datos que ya almacenas.
Un ejemplo completo de trabajo.
requirePayment de @blockchain0x/mcp construye el desafío 402; webhooks.verify de @blockchain0x/node verifica la confirmación. Usted posee las dos pequeñas piezas intermedias: la verificación del estado de pago dentro de la herramienta y el controlador de webhook que marca a un pagador como pagado. A continuación se muestra un servidor MCP completo que expone una herramienta de pago más su punto final de webhook.
import express from "express";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { requirePayment } from "@blockchain0x/mcp";
import { webhooks } from "@blockchain0x/node";
const server = new McpServer({ name: "docs-search", version: "1.0.0" });
// You decide who counts as paid. Back this with Redis/Postgres in production.
const paid = new Set<string>();
server.tool(
"search_docs",
"Semantic search across our docs",
{ query: { type: "string" }, payer: { type: "string" } },
async ({ query, payer }) => {
if (!paid.has(`search_docs:${payer}`)) {
// Not paid yet: build an x402-compatible 402 challenge and return its
// body as a tool error. requirePayment is a challenge builder - it does
// not gate the call for you; this check is yours.
const { body } = requirePayment({
amountUsdc: "0.02",
payTo: "0xYourMcpAgentAddress",
hostedUrl: "https://pay.blockchain0x.com/checkout/docs-search",
description: "docs search",
});
return { content: [{ type: "text", text: JSON.stringify(body) }], isError: true };
}
const results = await runVectorSearch(query);
return { content: [{ type: "text", text: JSON.stringify(results) }] };
},
);
// Your webhook endpoint marks a payer as paid once the checkout settles.
const app = express();
app.post("/webhooks/blockchain0x", express.raw({ type: "*/*" }), (req, res) => {
const r = webhooks.verify({ headers: req.headers, rawBody: req.body, secret: process.env.BLOCKCHAIN0X_WEBHOOK_SECRET! });
if (!r.ok) return res.status(400).json({ code: r.code });
if (r.eventType === "payment.received") {
// Resolve (tool, payer) from the reference you encoded in hostedUrl, then:
paid.add("search_docs:0xPayer");
}
res.json({ received: true });
});Pasos de configuración
- 1Crea una billetera de agente Blockchain0x para tu servidor MCP, en un plan que incluye acceso a la API y al webhook. Toma nota de la dirección de la billetera que usarás como payTo.
- 2Instala los paquetes:
npm install @blockchain0x/mcp @blockchain0x/node - 3Establecer variables de entorno: BLOCKCHAIN0X_API_KEY (el servidor MCP lo envía como Authorization: Bearer) y BLOCKCHAIN0X_WEBHOOK_SECRET (el secreto de firma del panel de control que verifica webhooks.verify).
- 4Controla tus herramientas pagadas verificando tu propio estado de pago y devolviendo el cuerpo del desafío requirePayment cuando el llamador no ha pagado. Deja las herramientas gratuitas sin control.
- 5Configura el endpoint del webhook en el panel de control de Blockchain0x (por ejemplo /webhooks/blockchain0x), luego verifica cada entrega con webhooks.verify y marca al pagador como pagado en payment.received.
- 6Desplegar. El primer cliente de IA que accede a tu herramienta de pago recibe un 402, paga y la siguiente llamada tiene éxito. Verás el pago en el panel dentro de 10 segundos.
También puedes ejecutar el servidor MCP de Blockchain0x con npx @blockchain0x/mcp (stdio) o el contenedor HTTP Streamable alojado en mcp.blockchain0x.com. La configuración completa, incluidos los formatos de carga útil del webhook, está en la documentación.
La decisión más importante en tu controlador.
Debido a que posees el estado de pago, también decides cuánto tiempo cuenta un pago. Después de que un cliente paga por una herramienta, mantenlo marcado como pagado durante un período de tiempo, y dentro de esa ventana deja pasar llamadas sin un nuevo pago. Establece la ventana demasiado corta y castigas a los clientes con fricción de pago en cada llamada; establece la ventana demasiado larga y regalas operaciones costosas después de un pago barato. Un TTL en tu clave de Redis/Postgres es la forma más sencilla de implementarlo.
Las ventanas que recomendamos
| Tipo de herramienta | Ventana | Por qué |
|---|---|---|
| Búsqueda barata ($0.01-$0.05) | 60 segundos | Absorbe reintentos naturales y llamadas de seguimiento sin revelar una sesión. |
| Inferencia de precio medio ($0.10-$1) | 30 segundos | Pagar por llamada es la forma correcta; la caché breve maneja reintentos en errores transitorios. |
| Contexto largo caro ($1-$10) | 0 segundos (sin caché) | Cada llamada es su propio evento pagado; sin caché. |
| Herramientas de estilo de suscripción | 24 horas | Paga una vez al día por llamadas ilimitadas dentro de la ventana. Mayor ingreso por cliente con menor fricción. |
Asigna tu estado de pago por par (billetera del pagador, herramienta), como lo hace el ejemplo con search_docs:0xPayer. Dos clientes diferentes acceden a la misma herramienta, cada uno paga por separado. El mismo cliente accede a dos herramientas diferentes, se requieren dos pagos separados. Puedes ampliarlo más (por pagador en todas las herramientas) si lo prefieres; la granularidad por pagador por herramienta es lo que hace que la fijación de precios se sienta justa.
Cuatro formas de precios que funcionan para servidores MCP.
El precio es tu decisión: tú estableces la cantidad por herramienta en el middleware. A continuación se presentan los cuatro patrones que vemos con más frecuencia y qué formas de herramienta se ajustan.
Micro-precios por llamada
$0.01 - $0.05 por llamadaBúsqueda, consulta, clasificación, conversión de formato - operaciones baratas con alto volumen.
Menor fricción para los clientes; alinea el costo con el uso exactamente.
Mayor costo de transacción; solo funciona con un alto volumen de llamadas.
Precios medios por llamada
$0.10 - $1.00 por llamadaInferencia de LLM, generación, producción de contenido, cualquier cosa donde cada llamada haga trabajo real.
Equilibrado - valor claro por llamada, cantidad de transacciones manejable.
Mayor fricción por llamada; los clientes a veces prefieren suscripciones en este rango de precios.
Precios altos por llamada
$1 - $10 por llamadaGeneración de contexto largo, procesamiento de documentos, orquestación de múltiples pasos, envoltura costosa de API de terceros.
El margen por llamada es significativo; los pagos fallidos son pérdidas tolerables.
Los clientes negocian duro a este precio; espera solicitudes de reembolso.
Ventana de suscripción
$5 - $50 por ventana de 24h (o $X por mes)Clientes que realizan muchas llamadas en una sesión y no tolerarían la fricción de pago por llamada.
Mayor ingreso por cliente; menos costos por llamada.
Menor descubribilidad; los clientes deben comprometerse por adelantado. A menudo combinado con por llamada para precios híbridos.
Muchos operadores mezclan patrones: herramientas baratas con micro-precios por llamada, herramientas caras con precios altos por llamada, además de una ventana de suscripción de 24 horas para usuarios frecuentes. Nada te impide ejecutar las tres en el mismo servidor MCP; cada herramienta establece su propio amountUsdc en requirePayment y su propia ventana de pago en tu controlador.
Pro es el plan adecuado para casi todos los servidores MCP.
Los operadores de servidores MCP casi siempre comienzan en Pro porque se requiere acceso de escritura a la API y webhooks desde el primer día: Free es de solo lectura, y una herramienta de pago necesita recibir webhooks de payment.received y verificarlos. Consulta la página de precios para conocer el costo exacto por agente y dónde se sitúan los niveles de tarifas de transacción; la versión corta es que cualquier servidor que maneje un volumen real de pagos está muy por encima del punto donde Pro se paga por sí mismo.
- Free: útil para experimentar con la API y el panel. No es viable para herramientas de pago en producción (solo lectura, sin webhooks).
- Pro: la opción predeterminada para servidores MCP en producción. Acceso completo a la API, webhooks, exportaciones.
- Business: cuando necesitas el registro de auditoría para compliance, o cuando operas servidores MCP para varios clientes y quieres compartición de asientos de equipo por agente.