Monétisez votre serveur MCP en 10 minutes.
Laissez les agents IA payer votre serveur MCP par appel, en USDC, avec des webhooks signés et des journaux d'audit. Compatible x402. Middleware à insérer.
Vous avez construit un serveur MCP. Des milliers de clients l'utilisent gratuitement.
Vous avez expédié votre serveur MCP parce que les clients Claude Desktop, Cursor et Cline avaient besoin de cette capacité. La nouvelle s'est répandue. Vous servez maintenant des milliers d'invocations d'outils payants par jour provenant d'agents IA que vous n'avez jamais rencontrés. Votre facture de sortie est réelle. Votre clé API pour le service sous-jacent est réelle. Votre temps de maintenance est réel. Les revenus sont nuls.
Vous avez trois options. Gardez-le gratuit et brûlez de l'argent sur l'infrastructure. Mettez-le derrière des clés API manuelles (et perdez 95 % du trafic des agents à cause de la friction des formulaires d'inscription). Ou ajoutez une couche de paiement que les agents IA peuvent réellement compléter - ce pour quoi 402 Payment Required + USDC est construit.
Blockchain0x est l'option trois. Votre serveur MCP pointe vers notre API. Lorsque un client AI appelle un outil payant, la réponse est 402 avec une URL de paiement hébergée. Le client (ou son superviseur humain) paie en USDC. Votre webhook se déclenche. Le prochain appel de ce client réussit. La forme entière s'appelle x402, et c'est le protocole que Coinbase a publié pour ce modèle exact.
Comment 402 Payment Required devient un paiement programmatique.
Le code d'état HTTP 402 existe depuis que la spécification a été écrite pour la première fois mais n'a jamais eu d'implémentation standard. Le protocole x402 de Coinbase lui en donne enfin une. La forme est simple : votre outil retourne un défi 402 (un corps JSON structuré décrivant comment payer) ; le client paie et réessaie ; l'appel réussit. requirePayment de @blockchain0x/mcp construit ce corps de défi pour vous.
{
"error": "payment_required",
"amountUsdc": "0.02",
"payTo": "0xYourMcpAgentAddress",
"hostedUrl": "https://pay.blockchain0x.com/checkout/docs-search",
"network": "mainnet",
"description": "docs search"
}Les quatre états
- Appel impayé : Le client AI invoque un outil payant. Votre gestionnaire vérifie votre propre état de paiement, constate que le payeur n'est pas marqué comme payé et renvoie le corps du défi 402 de requirePayment comme une erreur d'outil.
- Paiement : Le client suit l'URL hébergée vers le paiement hébergé et complète le transfert USDC sur Base (soit de manière programmatique via un portefeuille compatible x402, soit manuellement via un code QR).
- Webhook : Blockchain0x déclenche payment.received à votre point de terminaison dans les secondes suivant la confirmation de la chaîne. Vous le vérifiez avec webhooks.verify et enregistrez le payeur comme payé dans votre propre magasin.
- Réessayer : Le client réessaie l'appel de l'outil MCP d'origine. Votre gestionnaire voit maintenant le payeur marqué comme payé, exécute l'outil et renvoie le résultat réel.
Chaque paiement est enregistré dans votre tableau de bord Blockchain0x, et chaque webhook payment.received atterrit dans vos propres journaux. Parce que vous possédez l'état de paiement et le gestionnaire de webhook, les analyses de revenus par outil et par payeur découlent des données que vous stockez déjà.
Un exemple de travail complet.
requirePayment de @blockchain0x/mcp construit le défi 402 ; webhooks.verify de @blockchain0x/node vérifie la confirmation. Vous possédez les deux petites pièces entre les deux : la vérification de l'état de paiement à l'intérieur de l'outil, et le gestionnaire de webhook qui marque un payeur comme payé. Ci-dessous se trouve un serveur MCP complet qui expose un outil payant ainsi que son point de terminaison 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 });
});Étapes de configuration
- 1Créer un portefeuille d'agent Blockchain0x pour votre serveur MCP, sur un plan qui inclut l'accès à l'API et aux webhooks. Notez l'adresse du portefeuille que vous utiliserez comme payTo.
- 2Installer les packages :
npm install @blockchain0x/mcp @blockchain0x/node - 3Définir les variables d'environnement : BLOCKCHAIN0X_API_KEY (le serveur MCP l'envoie en tant qu'Authorization: Bearer) et BLOCKCHAIN0X_WEBHOOK_SECRET (le secret de signature du tableau de bord que webhooks.verify vérifie).
- 4Restreindre vos outils payants en vérifiant votre propre état de paiement et en renvoyant le corps du défi requirePayment lorsque l'appelant n'a pas payé. Laissez les outils gratuits non restreints.
- 5Configurer le point de terminaison du webhook dans le tableau de bord Blockchain0x (par exemple /webhooks/blockchain0x), puis vérifiez chaque livraison avec webhooks.verify et marquez le payeur comme payé sur payment.received.
- 6Déployer. Le premier client IA qui utilise votre outil payant reçoit un 402, paie, et l'appel suivant réussit. Vous voyez le paiement dans le tableau de bord dans les 10 secondes.
Vous pouvez également exécuter le serveur MCP Blockchain0x lui-même avec npx @blockchain0x/mcp (stdio) ou le conteneur HTTP Streamable hébergé à mcp.blockchain0x.com. La configuration complète, y compris les formes de charge utile du webhook, se trouve dans la documentation.
La décision la plus importante dans votre gestionnaire.
Parce que vous possédez l'état de paiement, vous décidez également combien de temps un paiement compte. Après qu'un client a payé pour un outil, gardez-le marqué comme payé pendant une certaine fenêtre de temps, et à l'intérieur de cette fenêtre, laissez passer les appels sans un nouveau paiement. Fixez la fenêtre trop courte et vous punissez les clients avec des frictions de paiement à chaque appel ; fixez-la trop longue et vous donnez des opérations coûteuses après un paiement bon marché. Un TTL sur votre clé Redis/Postgres est le moyen le plus simple de l'implémenter.
Les fenêtres que nous recommandons
| Type d'outil | Fenêtre | Pourquoi |
|---|---|---|
| Recherche bon marché (0,01 $ - 0,05 $) | 60 secondes | Absorbe les réessais naturels et les appels de suivi sans donner une session. |
| Inférence à prix moyen (0,10 $ - 1 $) | 30 secondes | Le paiement par appel est la bonne forme ; le cache temporaire gère la nouvelle tentative en cas d'erreurs transitoires. |
| Contexte long coûteux (1 $ - 10 $) | 0 secondes (pas de cache) | Chaque appel est son propre événement payant ; pas de mise en cache. |
| Outils de type abonnement | 24 heures | Payez une fois par jour pour des appels illimités dans la fenêtre. Revenus plus élevés par client avec moins de friction. |
Clé de votre état payé par paire (portefeuille payeur, outil), de la manière dont l'exemple le fait avec search_docs:0xPayer. Deux clients différents utilisent le même outil, chacun paie séparément. Le même client utilise deux outils différents, deux paiements séparés requis. Vous pouvez l'étendre plus largement (par payeur sur tous les outils) si vous le souhaitez ; la granularité par payeur par outil est ce qui rend la tarification équitable.
Quatre structures tarifaires qui fonctionnent pour les serveurs MCP.
La tarification est votre choix - vous définissez le montant par outil dans le middleware. Voici les quatre modèles que nous voyons le plus souvent et les formes d'outils auxquels ils correspondent.
Tarification micro par appel
$0.01 - $0.05 par appelRecherche, consultation, classification, conversion de format - opérations peu coûteuses avec un volume élevé.
Moins de friction pour les clients ; aligne le coût avec l'utilisation exactement.
Frais de transaction les plus élevés ; ne fonctionne qu'à un volume d'appels élevé.
Tarification intermédiaire par appel
$0.10 - $1.00 par appelInférence LLM, génération, production de contenu, tout ce où chaque appel fait un vrai travail.
Équilibré - valeur claire par appel, nombre de transactions gérable.
Friction plus élevée par appel ; les clients préfèrent parfois les abonnements à ce niveau de prix.
Tarification élevée par appel
$1 - $10 par appelGénération de long contexte, traitement de documents, orchestration multi-étapes, enveloppement d'API tierces coûteuses.
La marge par appel est significative ; les paiements échoués sont des pertes tolérables.
Les clients négocient fermement à ce prix ; attendez-vous à des demandes de remboursement.
Fenêtre d'abonnement
$5 - $50 par fenêtre de 24h (ou $X par mois)Clients qui effectuent de nombreux appels dans une session et ne toléreraient pas de friction de paiement par appel.
Revenu plus élevé par client ; moins de frais par appel.
Découverte réduite ; les clients doivent s'engager à l'avance. Souvent combiné avec un tarif par appel pour une tarification hybride.
De nombreux opérateurs mélangent les modèles : des outils bon marché à une tarification micro par appel, des outils coûteux à une tarification élevée par appel, plus une fenêtre d'abonnement de 24 heures pour les utilisateurs intensifs. Rien ne vous empêche de faire fonctionner les trois sur le même serveur MCP ; chaque outil définit son propre amountUsdc dans requirePayment et sa propre fenêtre payée dans votre gestionnaire.
Pro est le bon plan pour presque tous les serveurs MCP.
Les opérateurs de serveur MCP commencent presque toujours par Pro car l'accès en écriture à l'API et les webhooks sont requis dès le premier jour : le plan gratuit est en lecture seule, et un outil payant doit recevoir des webhooks payment.received et les vérifier. Consultez la page de tarification pour le coût exact par agent et où se situent les niveaux de frais de transaction ; la version courte est que tout serveur traitant un volume réel de paiements est bien au-delà du point où Pro se rembourse.
- Free : utile pour expérimenter avec l'API et le dashboard. Pas viable pour des outils payants en production (lecture seule, pas de webhooks).
- Pro: la formule par défaut pour les serveurs MCP en production. Accès API complet, webhooks, exports.
- Business : lorsque vous avez besoin du journal d'audit pour la conformité, ou lorsque vous exécutez des serveurs MCP pour plusieurs clients et souhaitez un partage des sièges d'équipe par agent.