Monetarisieren Sie Ihren MCP-Server in 10 Minuten.
Lassen Sie KI-Agenten Ihren MCP-Server pro Anruf in USDC mit signierten Webhooks und Prüfprotokollen bezahlen. x402-kompatibel. Drop-in-Middleware.
Sie haben einen MCP-Server gebaut. Tausende von Kunden nutzen ihn kostenlos.
Sie haben Ihren MCP-Server ausgeliefert, weil Claude Desktop, Cursor und Cline-Kunden diese Fähigkeit benötigten. Das Wort verbreitete sich. Sie bedienen jetzt täglich Tausende von Aufrufen bezahlter Tools von AI-Agenten, die Sie nie getroffen haben. Ihre Ausgabenrechnung ist real. Ihr API-Schlüssel für den zugrunde liegenden Dienst ist real. Ihre Wartungszeit ist real. Der Umsatz beträgt null.
Sie haben drei Optionen. Halten Sie es kostenlos und verbrennen Sie Geld für Infrastruktur. Sperren Sie es hinter manuellen API-Schlüsseln (und verlieren Sie 95% des Agentenverkehrs aufgrund der Reibung durch Anmeldeformulare). Oder fügen Sie eine Zahlungsschicht hinzu, die AI-Agenten tatsächlich abschließen können - genau dafür ist 402 Payment Required + USDC gebaut.
Blockchain0x ist Option drei. Ihr MCP-Server zeigt auf unsere API. Wenn ein KI-Client ein kostenpflichtiges Tool aufruft, ist die Antwort 402 mit einer gehosteten Zahlungs-URL. Der Client (oder sein menschlicher Aufseher) bezahlt in USDC. Ihr Webhook wird ausgelöst. Der nächste Aufruf von diesem Client ist erfolgreich. Die gesamte Form wird x402 genannt, und es ist das Protokoll, das Coinbase für dieses genaue Muster veröffentlicht hat.
Wie 402 Payment Required zu einem programmgesteuerten Checkout wird.
Der HTTP-Statuscode 402 existiert seit der ersten Erstellung der Spezifikation, hatte jedoch nie eine standardisierte Implementierung. Das x402-Protokoll von Coinbase gibt ihm endlich eine. Die Struktur ist einfach: Ihr Tool gibt eine 402-Herausforderung zurück (einen strukturierten JSON-Körper, der beschreibt, wie man bezahlt); der Client bezahlt und versucht es erneut; der Aufruf gelingt. requirePayment von @blockchain0x/mcp erstellt diesen Herausforderungs-Körper für Sie.
{
"error": "payment_required",
"amountUsdc": "0.02",
"payTo": "0xYourMcpAgentAddress",
"hostedUrl": "https://pay.blockchain0x.com/checkout/docs-search",
"network": "mainnet",
"description": "docs search"
}Die vier Zustände
- Unbezahlter Anruf: AI-Kunde ruft ein kostenpflichtiges Tool auf. Ihr Handler überprüft Ihren eigenen Zahlungsstatus, stellt fest, dass der Zahler nicht als bezahlt markiert ist, und gibt den 402-Herausforderungsinhalt von requirePayment als Toolfehler zurück.
- Zahlung: Der Kunde folgt der hostedUrl zum gehosteten Checkout und schließt die USDC-Übertragung auf Base ab (entweder programmgesteuert über eine x402-bewusste Wallet oder manuell über einen QR-Code).
- Webhook: Blockchain0x sendet payment.received an Ihren Endpunkt innerhalb von Sekunden nach der Bestätigung der Kette. Sie verifizieren es mit webhooks.verify und zeichnen den Zahler in Ihrem eigenen Speicher als bezahlt auf.
- Wiederholen: Der Kunde wiederholt den ursprünglichen MCP-Toolaufruf. Ihr Handler sieht jetzt den Zahler als bezahlt markiert, führt das Tool aus und gibt das tatsächliche Ergebnis zurück.
Jede Zahlung wird in Ihrem Blockchain0x-Dashboard aufgezeichnet, und jeder payment.received Webhook landet in Ihren eigenen Protokollen. Da Sie den bezahlten Zustand und den Webhook-Handler besitzen, ergeben sich Einnahmenanalysen pro Tool und pro Zahler aus den Daten, die Sie bereits speichern.
Ein vollständiges Arbeitsbeispiel.
requirePayment von @blockchain0x/mcp erstellt die 402-Herausforderung; webhooks.verify von @blockchain0x/node überprüft die Bestätigung. Sie besitzen die beiden kleinen Teile dazwischen: die Überprüfung des bezahlten Status innerhalb des Tools und der Webhook-Handler, der einen Zahler als bezahlt markiert. Unten ist ein vollständiger MCP-Server, der ein kostenpflichtiges Tool sowie seinen Webhook-Endpunkt bereitstellt.
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 });
});Einrichtungsschritte
- 1Erstellen Sie eine Blockchain0x-Agenten-Wallet für Ihren MCP-Server, auf einem Plan, der API- und Webhook-Zugriff umfasst. Notieren Sie die Wallet-Adresse, die Sie als payTo verwenden werden.
- 2Installieren Sie die Pakete:
npm install @blockchain0x/mcp @blockchain0x/node - 3Umgebungsvariablen setzen: BLOCKCHAIN0X_API_KEY (der MCP-Server sendet es als Authorization: Bearer) und BLOCKCHAIN0X_WEBHOOK_SECRET (das Dashboard-Signaturgeheimnis, gegen das webhooks.verify prüft).
- 4Schützen Sie Ihre kostenpflichtigen Tools, indem Sie Ihren eigenen Zahlungsstatus überprüfen und den requirePayment-Herausforderungsinhalt zurückgeben, wenn der Anrufer nicht bezahlt hat. Lassen Sie kostenlose Tools ungeschützt.
- 5Konfigurieren Sie den Webhook-Endpunkt im Blockchain0x-Dashboard (zum Beispiel /webhooks/blockchain0x), verifizieren Sie dann jede Lieferung mit webhooks.verify und markieren Sie den Zahler als bezahlt bei payment.received.
- 6Bereitstellen. Der erste KI-Client, der Ihr kostenpflichtiges Tool erreicht, erhält einen 402, bezahlt und der nächste Aufruf gelingt. Sie sehen die Zahlung innerhalb von 10 Sekunden im Dashboard.
Sie können den Blockchain0x MCP-Server auch selbst mit npx @blockchain0x/mcp (stdio) oder dem gehosteten Streamable HTTP-Container unter mcp.blockchain0x.com ausführen. Die vollständige Einrichtung, einschließlich der Webhook-Nutzlastformen, finden Sie in der Dokumentation.
Die wichtigste Entscheidung in Ihrem Handler.
Da Sie den bezahlten Zustand besitzen, entscheiden Sie auch, wie lange eine Zahlung zählt. Nachdem ein Kunde für ein Tool bezahlt hat, halten Sie ihn für einen bestimmten Zeitraum als bezahlt markiert und lassen innerhalb dieses Zeitraums Anfragen ohne eine frische Zahlung durch. Setzen Sie das Zeitfenster zu kurz, und Sie bestrafen die Kunden mit Zahlungsfriktionen bei jedem Anruf; setzen Sie es zu lange, und Sie verschenken teure Operationen nach einer günstigen Zahlung. Ein TTL auf Ihrem Redis/Postgres-Schlüssel ist der einfachste Weg, dies umzusetzen.
Die Zeitfenster, die wir empfehlen
| Tooltyp | Fenster | Warum |
|---|---|---|
| Günstige Abfrage ($0.01-$0.05) | 60 Sekunden | Absorbiert natürliche Wiederholungen und Folgeanrufe, ohne eine Sitzung preiszugeben. |
| Mittelpreisige Inferenz ($0.10-$1) | 30 Sekunden | Zahlung pro Anruf ist die richtige Form; der kurze Cache verarbeitet Wiederholungen bei vorübergehenden Fehlern. |
| Teurer Langkontext ($1-$10) | 0 Sekunden (kein Cache) | Jeder Anruf ist ein eigenes kostenpflichtiges Ereignis; kein Caching. |
| Abonnementstools | 24 Stunden | Zahlen Sie einmal täglich für unbegrenzte Anrufe innerhalb des Zeitfensters. Höhere Einnahmen pro Kunde bei geringerem Aufwand. |
Schlüsseln Sie Ihren bezahlten Zustand pro (Zahler-Brieftasche, Tool)-Paar, so wie das Beispiel es mit search_docs:0xPayer tut. Zwei verschiedene Clients verwenden dasselbe Tool, jeder zahlt separat. Derselbe Client verwendet zwei verschiedene Tools, zwei separate Zahlungen erforderlich. Sie können es breiter anlegen (pro Zahler über alle Tools), wenn Sie möchten; die Granularität pro Zahler und pro Tool ist es, die die Preisgestaltung fair erscheinen lässt.
Vier Preisgestaltungen, die für MCP-Server funktionieren.
Die Preisgestaltung liegt bei Ihnen - Sie legen den Betrag pro Tool in der Middleware fest. Unten sind die vier Muster aufgeführt, die wir am häufigsten sehen und in welche Toolformen sie passen.
Pro-Anruf-Mikropreisgestaltung
$0.01 - $0.05 pro AnrufSuche, Nachschlagen, Klassifizierung, Formatkonvertierung - kostengünstige Operationen mit hohem Volumen.
Geringste Reibung für Kunden; Kosten stimmen genau mit der Nutzung überein.
Höchster Transaktionsaufwand; funktioniert nur bei hohem Anrufvolumen.
Pro-Anruf-Mittelpreisgestaltung
$0.10 - $1.00 pro AnrufLLM-Inferenz, -Generierung, -Inhaltsproduktion, alles, wo jeder Aufruf echte Arbeit leistet.
Ausgewogen - klarer Wert pro Aufruf, überschaubare Transaktionsanzahl.
Höhere Reibung pro Anruf; Kunden ziehen manchmal Abonnements zu diesem Preis vor.
Pro-Anruf-Hochpreisgestaltung
$1 - $10 pro AnrufLangkontextgenerierung, Dokumentenverarbeitung, mehrstufige Orchestrierung, teures Einbinden von Drittanbieter-APIs.
Die Marge pro Anruf ist bedeutend; fehlgeschlagene Zahlungen sind tolerierbare Verluste.
Kunden verhandeln hart bei diesem Preis; erwarten Sie Rückerstattungsanfragen.
Abonnementfenster
$5 - $50 pro 24h-Fenster (oder $X pro Monat)Kunden, die viele Anrufe in einer Sitzung tätigen und keine Zahlungsprobleme pro Anruf tolerieren würden.
Höherer Umsatz pro Kunde; weniger Overhead pro Anruf.
Geringere Auffindbarkeit; Kunden müssen sich im Voraus verpflichten. Oft kombiniert mit pro Anruf für hybride Preisgestaltung.
Viele Betreiber mischen Muster: günstige Tools mit Mikropreisen pro Aufruf, teure Tools mit hohen Preisen pro Aufruf, plus ein 24-Stunden-Abonnementfenster für Vielnutzer. Nichts hindert Sie daran, alle drei auf demselben MCP-Server auszuführen; jedes Tool legt seinen eigenen amountUsdc in requirePayment und sein eigenes bezahltes Fenster in Ihrem Handler fest.
Pro ist der richtige Plan für fast jeden MCP-Server.
MCP-Serverbetreiber beginnen fast immer mit Pro, da API-Schreibzugriff und Webhooks von Anfang an erforderlich sind: Kostenlos ist schreibgeschützt, und ein kostenpflichtiges Tool muss payment.received-Webhooks empfangen und diese überprüfen. Siehe die Preisseite für die genauen Kosten pro Agent und wo die Transaktionsgebührenstufen liegen; die kurze Version ist, dass jeder Server, der echtes bezahltes Volumen verarbeitet, weit über dem Punkt liegt, an dem Pro sich selbst trägt.
- Free: nützlich zum Experimentieren mit der API und dem Dashboard. Nicht geeignet für produktive bezahlte Tools (nur lesen, keine Webhooks).
- Pro: der Standard für Live-MCP-Server. Voller API-Zugriff, Webhooks, Exporte.
- Business: wenn Sie das Audit-Log für Compliance benötigen oder wenn Sie MCP-Server für mehrere Kunden betreiben und eine Team-Sitzfreigabe pro Agent wünschen.