Monetize seu servidor MCP em 10 minutos.
Deixe os agentes de IA pagarem seu servidor MCP por chamada, em USDC, com webhooks assinados e registros de auditoria. Compatível com x402. Middleware de fácil integração.
Você construiu um servidor MCP. Milhares de clientes estão usando-o gratuitamente.
Você lançou seu servidor MCP porque os clientes Claude Desktop, Cursor e Cline precisavam da capacidade. A notícia se espalhou. Agora você está atendendo milhares de invocações de ferramentas pagas por dia de agentes de IA que você nunca conheceu. Sua conta de saída é real. Sua chave de API para o serviço subjacente é real. Seu tempo de manutenção é real. A receita é zero.
Você tem três opções. Mantenha-o gratuito e queime dinheiro em infraestrutura. Coloque-o atrás de chaves de API manuais (e perca 95% do tráfego de agentes devido à fricção dos formulários de cadastro). Ou adicione uma camada de pagamento que os agentes de IA possam realmente completar - que é exatamente para isso que 402 Payment Required + USDC foi construído.
Blockchain0x é a opção três. Seu servidor MCP aponta para nossa API. Quando um cliente de IA chama uma ferramenta paga, a resposta é 402 com uma URL de pagamento hospedada. O cliente (ou seu supervisor humano) paga em USDC. Seu webhook é acionado. A próxima chamada desse cliente é bem-sucedida. Toda a forma é chamada x402, e é o protocolo que a Coinbase publicou para esse padrão exato.
Como 402 Payment Required se torna um checkout programático.
O código de status HTTP 402 existe desde que a especificação foi escrita pela primeira vez, mas nunca teve uma implementação padrão. O protocolo x402 da Coinbase finalmente lhe dá uma. A estrutura é simples: sua ferramenta retorna um desafio 402 (um corpo JSON estruturado descrevendo como pagar); o cliente paga e tenta novamente; a chamada é bem-sucedida. requirePayment de @blockchain0x/mcp constrói esse corpo de desafio para você.
{
"error": "payment_required",
"amountUsdc": "0.02",
"payTo": "0xYourMcpAgentAddress",
"hostedUrl": "https://pay.blockchain0x.com/checkout/docs-search",
"network": "mainnet",
"description": "docs search"
}Os quatro estados
- Chamada não paga: O cliente de IA invoca uma ferramenta paga. Seu manipulador verifica seu próprio estado de pagamento, descobre que o pagador não está marcado como pago e retorna o corpo do desafio 402 do requirePayment como um erro da ferramenta.
- Pagamento: O cliente segue o hostedUrl até o checkout hospedado e completa a transferência de USDC na Base (programaticamente via uma carteira ciente do x402 ou manualmente via QR code).
- Webhook: Blockchain0x dispara payment.received para seu endpoint dentro de segundos após a confirmação da blockchain. Você verifica com webhooks.verify e registra o pagador como pago em seu próprio armazenamento.
- Tentar novamente: O cliente tenta novamente a chamada da ferramenta MCP original. Seu manipulador agora vê o pagador marcado como pago, executa a ferramenta e retorna o resultado real.
Cada pagamento é registrado no seu painel Blockchain0x, e cada webhook payment.received chega nos seus próprios logs. Como você possui o estado pago e o manipulador de webhook, as análises de receita por ferramenta e por pagador surgem dos dados que você já armazena.
Um exemplo completo de funcionamento.
requirePayment de @blockchain0x/mcp constrói o desafio 402; webhooks.verify de @blockchain0x/node verifica a confirmação. Você possui as duas pequenas peças entre elas: a verificação do estado pago dentro da ferramenta e o manipulador de webhook que marca um pagador como pago. Abaixo está um servidor MCP completo que expõe uma ferramenta paga e seu endpoint 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 });
});Passos de configuração
- 1Crie uma carteira de agente Blockchain0x para seu servidor MCP, em um plano que inclui acesso à API e ao webhook. Anote o endereço da carteira que você usará como payTo.
- 2Instale os pacotes:
npm install @blockchain0x/mcp @blockchain0x/node - 3Defina as variáveis de ambiente: BLOCKCHAIN0X_API_KEY (o servidor MCP o envia como Authorization: Bearer) e BLOCKCHAIN0X_WEBHOOK_SECRET (o segredo de assinatura do painel com o qual webhooks.verify faz a validação).
- 4Controle suas ferramentas pagas verificando seu próprio estado de pagamento e retornando o corpo do desafio requirePayment quando o chamador não pagou. Deixe ferramentas gratuitas sem controle.
- 5Configure o endpoint do webhook no painel do Blockchain0x (por exemplo /webhooks/blockchain0x), depois verifique cada entrega com webhooks.verify e marque o pagador como pago em payment.received.
- 6Implantar. O primeiro cliente de IA que acessa sua ferramenta paga recebe um 402, paga, e a próxima chamada é bem-sucedida. Você vê o pagamento no painel em até 10 segundos.
Você também pode executar o servidor MCP do Blockchain0x com npx @blockchain0x/mcp (stdio) ou o contêiner HTTP Streamable hospedado em mcp.blockchain0x.com. A configuração completa, incluindo as formas de carga útil do webhook, está na documentação.
A decisão mais importante no seu manipulador.
Porque você possui o estado pago, você também decide quanto tempo um pagamento conta. Depois que um cliente paga por uma ferramenta, mantenha-o marcado como pago por um determinado período de tempo e, dentro dessa janela, permita chamadas sem um novo pagamento. Defina a janela muito curta e você pune os clientes com fricção de pagamento em cada chamada; defina-a muito longa e você dá operações caras após um pagamento barato. Um TTL na sua chave Redis/Postgres é a maneira mais simples de implementá-lo.
As janelas que recomendamos
| Tipo de ferramenta | Janela | Por que |
|---|---|---|
| Consulta barata ($0.01-$0.05) | 60 segundos | Absorve tentativas naturais e chamadas de acompanhamento sem revelar uma sessão. |
| Inferência de preço médio ($0,10-$1) | 30 segundos | Pagar por chamada é a forma certa; o cache breve lida com a repetição de erros transitórios. |
| Consulta longa cara ($1-$10) | 0 segundos (sem cache) | Cada chamada é seu próprio evento pago; sem cache. |
| Ferramentas de estilo de assinatura | 24 horas | Pague uma vez por dia por chamadas ilimitadas dentro da janela. Maior receita por cliente com menor atrito. |
Chave seu estado de pagamento por par (carteira do pagador, ferramenta), da maneira que o exemplo faz com search_docs:0xPayer. Dois clientes diferentes acessam a mesma ferramenta, cada um paga separadamente. O mesmo cliente acessa duas ferramentas diferentes, dois pagamentos separados são necessários. Você pode ampliar isso (por pagador em todas as ferramentas) se preferir; a granularidade por pagador por ferramenta é o que faz o preço parecer justo.
Quatro formas de precificação que funcionam para servidores MCP.
A definição de preços é sua - você define o valor por ferramenta no middleware. Abaixo estão os quatro padrões que vemos com mais frequência e quais formatos de ferramenta eles se encaixam.
Precificação micro por chamada
$0,01 - $0,05 por chamadaPesquisa, consulta, classificação, conversão de formato - operações baratas com alto volume.
Menor atrito para os clientes; alinha o custo com o uso exatamente.
Maior custo de transação; funciona apenas em alto volume de chamadas.
Precificação média por chamada
$0,10 - $1,00 por chamadaInferência LLM, geração, produção de conteúdo, qualquer coisa onde cada chamada faz trabalho real.
Equilibrado - valor claro por chamada, contagem de transações gerenciável.
Maior atrito por chamada; os clientes às vezes preferem assinaturas nesse ponto de preço.
Precificação alta por chamada
$1 - $10 por chamadaGeração de longo contexto, processamento de documentos, orquestração de múltiplas etapas, envolvimento caro de API de terceiros.
A margem por chamada é significativa; pagamentos falhados são perdas toleráveis.
Os clientes negociam duro a este preço; espere pedidos de reembolso.
Janela de assinatura
$5 - $50 por janela de 24h (ou $X por mês)Clientes que fazem muitas chamadas em uma sessão e não tolerariam atritos de pagamento por chamada.
Maior receita por cliente; menos custos por chamada.
Menor descobribilidade; os clientes devem se comprometer antecipadamente. Frequentemente combinado com por chamada para preços híbridos.
Muitos operadores misturam padrões: ferramentas baratas com micro-preços por chamada, ferramentas caras com preços altos por chamada, além de uma janela de assinatura de 24 horas para usuários pesados. Nada impede você de executar os três no mesmo servidor MCP; cada ferramenta define seu próprio amountUsdc em requirePayment e sua própria janela de pagamento em seu manipulador.
Pro é o plano certo para quase todos os servidores MCP.
Os operadores de servidores MCP quase sempre começam no Pro porque o acesso de gravação da API e os webhooks são necessários desde o primeiro dia: o Free é somente leitura, e uma ferramenta paga precisa receber webhooks payment.received e verificá-los. Veja a página de preços para o custo exato por agente e onde os níveis de taxa de transação estão; a versão curta é que qualquer servidor que faça volume pago real está muito além do ponto em que o Pro se paga.
- Free: útil para experimentar a API e o dashboard. Não é viável para ferramentas pagas em produção (somente leitura, sem webhooks).
- Pro: o padrão para servidores MCP ao vivo. Acesso total à API, webhooks, exports.
- Business: quando você precisa do log de auditoria para compliance, ou quando executa servidores MCP para vários clientes e quer compartilhamento de assentos por agente.