AgentPay MCP

Kompatibel mit x402 V1/V2 + Stripe MPP — protokollunabhängige Ausgabenkontrollen.

agentpay-mcp ist die Trust- und Policy-Ebene mit dem Menschen an erster Stelle, die über den standardisierten Ausführungsschienen (x402, ACP, UCP) liegt. OWS-kompatible Trust-Ebene -- funktioniert auf der Grundlage des MoonPay Open Wallet Standard. Protokollunabhängige Trust-Ebene -- funktioniert mit x402 UND Stripe MPP. Während x402 600 Mio. USD pro Jahr abwickelt — wobei KI-Agenten 40 % der Protokollaktivität ausmachen (März 2026) — ist das fehlende Puzzleteil nicht die Zahlungsausführung. Es ist die Governance: Wer hat es genehmigt, wie viel darf ausgegeben werden, und was passiert, wenn der Agent versucht, sein Budget zu überschreiten? Genau das bietet agentpay-mcp.

ACP regelt, was Agenten VERKAUFEN. agentpay-mcp regelt, was Agenten KAUFEN. ACP (Agent Commerce Protocol) ermöglicht es Agenten, Dienste anzubieten, zu verhandeln und Zahlungen zu empfangen. agentpay-mcp ist die komplementäre Ebene — sie kontrolliert, was Agenten ausgeben, wenn sie kostenpflichtige APIs, Tools und Dienste nutzen. Unterschiedliche Probleme, kompatible Lösungen.

Wenn Ihr Agent auf HTTP 402 Payment Required stößt, muss er zahlen und es erneut versuchen — mit Ihrer Genehmigung und innerhalb der von Ihnen festgelegten Grenzen. AgentPay MCP ist ein Model Context Protocol-Server, der Claude, Cursor und jedem MCP-kompatiblen Agenten eine Zahlungs-Wallet mit harten Ausgabenobergrenzen, einem Modus für menschliche Genehmigung und einem vollständigen On-Chain-Prüfpfad bietet.

Das MCP-Ökosystem verzeichnet inzwischen mehr als 97 Mio. monatliche Downloads und mehr als 10.000 aktive Server — agentpay-mcp ist die einzige vollständige, MCP-native Zahlungsausführungsebene.

✅ Integriert in NVIDIA/NeMo-Agent-Toolkit-Examples (PR #17 gemergt) — Zahlungsinfrastruktur für NVIDIAs offizielles Agent-Toolkit.

📌 Flaggschiff-Angebot von AgentIndex und Sandbox-Zahlungsdemo: Wie Agenten API-Aufrufe sicher kaufen und Vertrauensergebnis von AgentPay MCP.

📌 Der Kontext zur x402-Ökosystem-Listung wird in docs/x402-ecosystem-submission.md nachverfolgt.

Wer nutzt agentpay-mcp?

agentpay-mcp wurde für drei Käufer-Personas entwickelt, die alle dasselbe Problem haben: autonome Agenten, die Geld ohne Kontrollen ausgeben.

FinOps-Teams: agentpay-mcp ist die erste Governance-Ebene, die für Ihre Workflows entwickelt wurde — nicht nur für Entwickler. Budget-Obergrenzen, Genehmigungsschwellen und Kostenzuordnung, die sich nahtlos in Ihr bestehendes FinOps-Tooling einfügen.

Related MCP server: 402-mcp

Warum Vertrauen wichtig ist

Die 2026 AI Trust Maturity Survey von McKinsey beziffert, was Entwickler bereits spüren: Die Fähigkeiten von Agenten haben die Agenten-Governance überholt.

Die Vertrauenslücke ist die Einführungslücke. Die Unternehmen sagen nicht, dass Agenten nicht funktionieren — sie sagen, dass die Aufsichtsinfrastruktur (Genehmigungsworkflows, Ausgaben-Leitplanken, Identitätsprüfung, Prüfpfade) nicht Schritt gehalten hat.

AgentPay MCP geht das direkt an:

• Modus für menschliche Genehmigung — Transaktionen über Ihrem Schwellenwert erfordern vor der Ausführung eine ausdrückliche menschliche Bestätigung

• On-Chain-Ausgabenobergrenzen — Limits des AgentAccountV2-Smart-Contracts, die Anwendungscode nicht außer Kraft setzen kann, wenn der Wallet-Inhaber sie im Vertrag konfiguriert hat. Das Tool set_spend_policy legt eine separate prozessinterne Policy fest (siehe docs/security-posture.md für die genauen Kontrollgrenzen)

• Prüfpfad — unveränderliche On-Chain-Ereignishistorie von AgentAccountV2 über get_transaction_history (Empfänger, Betrag, Blocknummer). Zahlungsversuche, die abgelehnt werden, bevor sie die Chain erreichen, werden nicht aufgezeichnet

• Fail-closed — jeder Fehler der Policy-Engine führt zu einer Ablehnung, niemals zu einer Genehmigung

• Non-Custodial — private Schlüssel verlassen niemals den lokalen Rechner

Wenn 88 % der Unternehmen bereits einen Sicherheitsvorfall mit Agenten hatten, ist „Vertrauen als Standard" keine tragfähige Architektur. AgentPay MCP ist für „Erst prüfen, dann vertrauen" gebaut — das einzige Modell, das skaliert.

Warum Kosten-Governance für MCP-Agenten wichtig ist

Das Model Context Protocol gibt Agenten Zugriff auf leistungsstarke Tools — aber das Protokoll selbst hat keinen eingebauten Mechanismus, um zu kontrollieren, was diese Tools kosten. Das ist keine theoretische Lücke. Der 2026er-Leitfaden von WorkOS zur MCP-Sicherheit identifiziert ausdrücklich Rate-Limiting, Kostenattribution und Ausgabenobergrenzen pro Aufruf als ungelöste Probleme auf der MCP-Protokollebene. Jeder MCP-Server kann Gebühren erheben. Kein MCP-Client setzt Budgets durch.

Das Ergebnis: Ein Agent mit Zugriff auf 10 MCP-Server kann über Sitzungen hinweg unbegrenzte Kosten anhäufen — ohne einen standardisierten Weg, Ausgaben pro Tool zuzuordnen, das Exposure pro Aufruf zu begrenzen oder außer Kontrolle geratene Schleifen zu stoppen, bevor sie eine Wallet leeren.

AgentPay MCP schließt diese Lücke auf der Infrastrukturebene:

Wenn Sie Agenten entwickeln, die mit kostenpflichtigen APIs interagieren, sind MCP-Ausgabelimits und MCP-Kosten-Governance keine Option — sie sind der Unterschied zwischen einer Demo und einer Produktionsbereitstellung. AgentPay MCP ist die Open-Source-Referenzimplementierung, um dies am Rand des Protokolls zu lösen.

Sicherheit & Abhängigkeiten

AgentPay MCP wurde für Unternehmens-MCP-Bereitstellungen entwickelt, bei denen Lieferketten-Sicherheit eine Rolle spielt.

• Keine LiteLLM-Abhängigkeit. Keine direkte oder transitive Abhängigkeit von LiteLLM oder einer schwergewichtigen LLM-Routing-Schicht. Als die LiteLLM-Versionen 1.82.7-1.82.8 im März 2026 auf PyPI kompromittiert wurden, waren Nutzer von AgentPay MCP nicht betroffen.

• Prüfbarer, minimaler Abhängigkeitsbaum. Der Server läuft auf viem, @modelcontextprotocol/sdk und einer kleinen Menge prüfbarer npm-Pakete. Kein PyPI. Keine Python-Laufzeit erforderlich.

• Enterprise-Vertrauenssignal. Integriert in die offiziellen NeMo Agent Toolkit Examples von NVIDIA (PR #17, gemerged). Der Überprüfungsprozess von NVIDIA hat die Sicherheitslage vor dem Merge validiert.

• Nicht-verwahrende Architektur. Private Schlüssel verlassen niemals den lokalen Rechner. On-Chain-Ausgabelimits setzen Grenzen durch, selbst wenn der Agent oder sein Schlüssel kompromittiert wird.

• Härtung der Vercel-Bereitstellung. Wenn Sie KI-Agenten auf Vercel bereitstellen, prüfen Sie die Checkliste zur Härtung der Vercel-Bereitstellung, bevor Sie kostenpflichtige Tools nach einer Offenlegung von OAuth, Dashboard, CI oder Umgebungsvariablen wieder verbinden.

• x402-Scanner-Bereitschaft. Verwenden Sie für kostenpflichtige API-Demos, die scannerlesbare x402-Unterstützung benötigen, das Rezept für x402-Scanner-Bereitschaft.

• x402-Bazaar-Beobachtbarkeit. Verwenden Sie für kostenpflichtige MCP-Tools, die in durchsuchbare Bazaar-Kataloge aufgenommen werden, das Rezept für x402-Bazaar-Beobachtbarkeit, um WithBazaar-Suchmetadaten, einheitliche Authentifizierung und das Auslesen von EXTENSION-RESPONSES abzudecken.

• x402-Batch-Settlement-Kanäle. Verwenden Sie für wiederholte kostenpflichtige MCP-Aufrufe mit Einzahlungs-, Gutschein-, Rückerstattungs- und Anspruchsabläufen das Rezept für x402-Batch-Settlement-Kanäle, um Kanalspeicher, Gutscheinlimits, Wiederherstellung und Off-Chain-Settlement-Prüfpfade produktionssicher zu halten.

• x402-Multi-SDK-Batch-Settlement-Parität. Verwenden Sie für Anbieter, die x402-TypeScript- und Go-Batch-Settlement-Clients testen, das Rezept für Multi-SDK-Batch-Settlement-Parität, um gemeinsamen Kanalstatus, phasenweise E2E-Ergebnisse, Trennung der Signierer, Sichtbarkeit von Rückerstattungen/Wiederherstellung und die Form des Proof-Bundles nachzuweisen.

• x402-TVM-Bereitschaft. Verwenden Sie für TVM/TON-Exact-Payment-Angebote aus aufkommenden x402-Beispielen den Hinweis zur x402-TVM-Bereitschaft, um zu bestätigen, dass nicht unterstützte TVM-Anforderungen fail-closed bleiben, bis eine bewusste Unterstützung für Signierung, Gas, Jetton und Settlement vorhanden ist.

• x402-MCP-Funding-UX. Verwenden Sie für Vergleiche von gehosteten Fund-Links und verwalteten Wallets den Benchmark zur x402-MCP-Funding-UX, um die Onboarding-Geschwindigkeit von Genehmigungsstufen, Tageslimits, Prüfbarkeit und nicht-verwahrenden Kontrollen zu trennen.

• Bereitschaft für Verzeichnis-Introspektion. Verwenden Sie für Glama, Smithery und andere MCP-Kataloge den Hinweis zur Bereitschaft für Verzeichnis-Introspektion für verifizierte npx-, Docker-, MCP-Namen- und nicht-verwahrende Metadatenpfade.

• x402-v2.11-Kompatibilität für kostenpflichtige MCPs. Verwenden Sie den Kompatibilitätsnachweis für Payment-Signature, payment-response, mcp-session-id, CORS-exponierte Header, die Initialisierungsreihenfolge von Streamable HTTP, Beleglinks und den Wechsel von Base Sepolia zu Base-Mainnet.

• Verzeichnisgeeigneter Metadaten-Nachweis. Verwenden Sie den Registry-/Listing-Nachweis, docs/mcp-registry-listing.json, glama.json, smithery.yaml und llms.txt für Katalog-Crawler und Käufer-Agenten.

• Kettenneutrales x402-Gateway-Profil. Verwenden Sie den Nachweis für das kettenneutrale Gateway-Profil, das Schema und die Fixture, um unterstützte Netzwerke, Facilitator-/Settlement-Metadaten, Test-/Rückerstattungsrichtlinien und Verzeichnismanifeste zu dokumentieren, ohne Base-spezifische Annahmen in die Non-EVM-Erkennung einfließen zu lassen.

• Multi-Ledger-x402-Belegnormalisierung. Verwenden Sie den Nachweis zur Multi-Ledger-Belegnormalisierung, das Schema und die XRPL-Fixture, um Ledger-Bezeichnungen, Assets, Settlement-Ziele, Payment-Signature, payment-response, Verifizierungsstatus, nicht-verwahrende Grenzen und Ablehnungen nicht unterstützter Ledger vor der Signierung zu normalisieren.

• Preflight-Profil für Wallet-Aktionen. Verwenden Sie das Preflight-Profil für Wallet-Aktionen und die TRON-Fixture, um vor irreversiblen Sendungen, Swaps oder Ressourcenkäufen Simulation, Ketten-/Ressourcenlimits, Allowlists, Bestätigung von Empfänger und Betrag, Nonce-Hinweise und Genehmigungstexte zu verlangen.

• Verzeichnislisting-Paket für Maschinenzahlungen. Verwenden Sie das Verzeichnislisting-Paket und das Listing-JSON für MPP- und Paid-MCP-Verzeichnisse, ohne nicht unterstützte Non-EVM-Signierung zu beanspruchen.

• Fünf-Tool-x402-Paritätsnachweis. Verwenden Sie den Fünf-Tool-Paritätsnachweis und die maschinenlesbare Zuordnung, um Such-, Prüf-, Abruf-, Wallet- und Zahlungsabläufe auf die lokalen Signierer- und genehmigungsgesteuerten Kontrollen von AgentPay abzubilden.

• Escrow- und Reputationsgrenze. Verwenden Sie den Nachweis der Escrow-/Reputationsgrenze, um die x402-Zahlungsautorisierung von Task-Escrow, Identität, Reputation und Arbeitsnachweis getrennt zu halten.

• Bereitschaft für Paid-MCP-Proxy und Discovery. Verwenden Sie das Paket für Paid-Proxy- und Discovery-Bereitschaft sowie das Listing-JSON für Toolstem-/Cinderwright-artige Proxy- und Verzeichniseinreichungen.

• Dynamische Manifestdrift bei Paid MCPs. Verwenden Sie den Nachweis der dynamischen Manifestdrift, das Schema und die Rug-Munch-Fixtures, um frische .well-known/x402-Schnappschüsse, Warnungen zu veralteten Metadaten, Klarheit über fehlende Testversionen/Preise, unterstützte Netzwerke und die Aktualität von Verzeichnis-Endpunkten zu validieren, bevor Käufer-Agenten signieren.

• Smithery-Installation für Paid MCPs. Verwenden Sie den Smithery-Installationsnachweis und examples/smithery-paid-mcp-installation für die Smithery-CLI, Vercel AI SDK MCP, @smithery/api, Genehmigungsstufen, Standard-Ausgabelimits und frische x402-Manifestprüfungen. Beanspruchen Sie keine Live-Smithery-Verifizierung, bis das Listing verifiziert ist.

• x402-nativ vs. Stripe-Proxy-MCP. Verwenden Sie für Entwickler, die AgentPay MCP mit aufkommenden Stripe-Proxy-MCP-Repos vergleichen, den Hinweis zu x402-nativ vs. Stripe-Proxy, um Genehmigungsstufen, Ausgabelimits, Audit-Zeilen und nicht-verwahrende Signierung von Proxy-Abrechnungsansprüchen getrennt zu halten.

• Verifizierung gehosteter x402-Proxys. Bevor ein Agent ein gehostetes x402-MCP-Gateway bezahlt, verwenden Sie die Käufer-Checkliste für gehostete x402-Proxys, um payment-required-Header, payTo ungleich null, Netzwerk- und Asset-Allowlists, Genehmigungsstatus, Ausgabelimit, Audit-Korrelation und Pooled-Token-Bindung zu verifizieren.

• Paid-MCP-Discovery und Budget-Antwort. Verwenden Sie für SettleGrid-artige Discovery-, Metering- und Budget-Plattform-Vergleiche die Paid-MCP-Discovery- und Budget-Antwort, um die Verzeichnis-Discovery von der x402-Käuferautorisierung zu trennen.

• Buyer-Flow-Parität für Ein-Befehl-x402-Tools. Verwenden Sie für AgentScore-Pay-artige Buyer-CLI-Vergleiche die Checkliste zur AgentPay-Buyer-Flow-Parität, um vor der Signierung Discovery, Prüfung, Trockenlauf, Zahlung, Ausgabelimits, typisierte Zahlungsfehler, Kontingentgrenzen, kostenlose Fehlschläge, Idempotenz, MCP-Exposition und Audit nachzuweisen.

• Härtung von Paid-MCP-Gateways. Verwenden Sie für create-mcpay-artige Worker-Gerüste die Checkliste zur Härtung von Paid-MCP-Gateways, um Anmeldung, Challenge-Parsing, Key-Minting, atomare Abrechnung, Standard-Scopes, Validierungsfehler ohne Berechnung und Buyer-Audit-Zeilen zu testen.

• Health-Nachweis für kostenpflichtige Anbieter. Verwenden Sie für Voidly-artige öffentliche Anbieter-Health-Feeds die Checkliste zum Health-Nachweis für kostenpflichtige Anbieter, um vor der Signierung die Erfolgsrate des Anbieters, veraltete Serien, Belegstatus, x402-Netzwerk, Asset, payTo und Fail-closed-Routing zu verifizieren.

• Qualitätsschwellen für kostenpflichtige Tools. Verwenden Sie für Strale-artige bewertete Kataloge den Nachweis der Qualitätsschwellen für kostenpflichtige Tools, um vor der x402-Signierung frische Bewertungsfelder, Warnungen zu veralteten Bewertungen, Anbieter-Health-Snapshots, Ablehnung bei Mindestqualität und Genehmigungsstufen zu verifizieren.

• Autorisierte Cybersicherheits-Scans. Verwenden Sie für AgentAegis-artige kostenpflichtige Sicherheitstools das Zahlungsprofil für autorisierte Cybersicherheits-Scans, um Zielautorisierung, Bindung an erlaubte Domains, Ausgabelimits pro Ziel, Scan-Raten-Richtlinie, Genehmigungsaufforderungen und Audit-Belegsprache zu verlangen.

• Post-Quanten-Kompatibilität von Ausgabe-Envelopes. Verwenden Sie für PQSafe-artige Käuferfragen die Bewertung der Post-Quanten-Ausgabe-Envelope-Kompatibilität, um Ausgabelimits, Allowlists, x402-Belege, Genehmigungsstufen und Audit-Metadaten abzubilden, ohne eine ML-DSA-Implementierung zu beanspruchen.

• Zahlungskritische Abhängigkeits-Pins. Für x402-Verifier- und Signierungspfade pinnt AgentPay viem exakt auf 2.52.2, erzwingt denselben Root-Override und führt vor der Veröffentlichung einen Clean-Install-Smoke-Test durch. Siehe die Richtlinie für Abhängigkeits-Pins.

• WhatsApp- und SMB-Agenten-Kontrollen. Verwenden Sie für kanalnative kostenpflichtige Agenten das Rezept für WhatsApp- und SMB-Paid-Agenten-Kontrollen.

• Affiliate-Auszahlungskontrollen für Kanal-Agenten. Verwenden Sie für Axon-artige Affiliate- und Empfehlungsumsatzbeteiligungen die Spezifikation für Kanal-Agenten-Affiliate-Kontrollen, um Auszahlungsobergrenzen, Genehmigung pro Kontakt, Audit-Zeilen und optionales x402-Settlement von der Ausgabengenehmigung für kostenpflichtige Tools getrennt zu halten.

• x402-Ketten-Drift. AgentPay MCP folgt der Paywall-Template-Baseline der x402 Foundation exakt mit viem 2.52.2 und verhält sich für nicht zugeordnete Ketten fail-closed. Für Änderungen an PaymentWrapper und Paywall-Templates befolgen Sie den Hinweis zur x402-Ketten-Drift-Kompatibilität.

Wenn Ihr Sicherheitsteam nach dem LiteLLM-Vorfall MCP-Server-Abhängigkeiten prüft, liefert Ihnen npm ls auf agentpay-mcp einen kurzen, überprüfbaren Baum ohne Python-Supply-Chain-Exposition.

Vertrauen & Governance — A2A-Protokoll-Ausrichtung

Das Agent2Agent (A2A)-Protokoll von Google (v1.0.0) legt fest, wie Agenten über Organisationsgrenzen hinweg einander entdecken, sich authentifizieren und zusammenarbeiten. Die Spezifikation ist um Agent Cards, Sicherheitsschemata und Human-in-the-Loop-Aufgabenverwaltung aufgebaut — aber sie definiert bewusst keine Ausgabengovernance auf Protokollebene.

agentpay-mcp schließt diese Lücke als komplementäre Governance-Ebene. So lassen sich unsere Kontrollen auf die A2A-Architektur abbilden:

Was das in der Praxis bedeutet

Wenn zwei A2A-konforme Agents bei einem Task zusammenarbeiten, der kostenpflichtige API-Aufrufe umfasst:

1. Discovery — Der aufrufende Agent liest die Agent Card des entfernten Agents (A2A-Spezifikation)

2. Authentifizierung — Gegenseitige Authentifizierung über deklarierte Sicherheitsschemata (A2A-Spezifikation)

3. Ausgaben-Governance — agentpay-mcp setzt Budgetlimits durch, protokolliert Transaktionen und sperrt hochwertige Zahlungen hinter menschlicher Genehmigung (agentpay-mcp-Ebene)

4. Audit — Vollständige On-Chain-Transaktionshistorie liefert Compliance-Nachweise unabhängig vom internen Zustand beider Agents

Dies positioniert agentpay-mcp als Ausgaben-Governance-Ebene für A2A-konforme Agent-Ökosysteme — und ergänzt die Identitäts- und Taskverwaltung des Protokolls um die finanziellen Kontrollen, die Unternehmen benötigen, bevor sie autonome Agents einsetzen.

Hinweis: Die A2A-v1.0.0-Spezifikation definiert keinen Vertrauens-Scoring- oder Vertrauenssignal-Mechanismus auf Protokollebene. Die Governance-Kontrollen von agentpay-mcp (Ausgabelimits, menschliche Genehmigung, On-Chain-Audit-Trails) sind so konzipiert, dass sie mit zukünftigen vertrauensbezogenen Erweiterungen kompatibel sind, während sich das A2A-Ökosystem weiterentwickelt.

KI-Agent-Discovery

AgentPay MCP ist darauf ausgelegt, von KI-Agents entdeckt und genutzt zu werden. Kompatibel mit:

• claude-mem – Zahlungszustand (Transaktionshistorie, Budgets, Sitzungstokens) bleibt über Sitzungen hinweg als Agent-Gedächtnis über die Beobachtungsebene von claude-mem erhalten

• AgentSkills – Als frameworkübergreifende Skill in jeder AgentSkills-kompatiblen Umgebung installierbar (Claude Code, Cursor, Gemini CLI, Antigravity)

• Chrome DevTools MCP – Kombinierbar als Zahlungsebene für browser-native Agents

Als Skill installieren

Zu jeder MCP-kompatiblen Umgebungskonfiguration hinzufügen:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x..."
      }
    }
  }
}

Funktioniert mit Claude Code, Cursor, Gemini CLI, OpenClaw, Windsurf und jedem MCP-Client.

Der 402-Flow — Was das tatsächlich bewirkt

Agent calls a paid API
        │
        ▼
   HTTP 402 ←── "Payment required: 0.50 USDC on Base"
        │
        ▼
AgentPay MCP evaluates your policy:
  • Is 0.50 USDC under your per-tx cap?  ($5 limit → ✅)
  • Is this recipient allowlisted?        (api.example.com → ✅)
  • Require human approval?              (under $1 threshold → auto)
        │
        ▼
  Payment sent → API retried with payment proof → 200 OK
        │
        ▼
Agent gets the data. Full tx on basescan.org.

agentpay-mcp vs. x402-mcp — Was ist der Unterschied?

Beide Projekte ermöglichen Agent-Zahlungen. Sie lösen unterschiedliche Probleme auf unterschiedlichen Ebenen.

Wann x402-mcp verwenden: Sie möchten die einfachstmögliche x402-Zahlungsintegration ohne Governance-Anforderungen. Ihr Agent arbeitet mit unbegrenzter Budgetbefugnis.

Wann agentpay-mcp verwenden: Sie benötigen Ausgabenkontrollen, Budgetdurchsetzung, menschliche Genehmigungsworkflows oder Multi-Protokoll-Unterstützung. Ihre Agents arbeiten mit realen Unternehmensbudgets, bei denen unkontrollierte Ausgaben ein Einsatzblocker sind.

x402-mcp fügt Ihrem Agent Zahlungen hinzu. agentpay-mcp fügt governed Zahlungen hinzu — Ausgabelimits, Sitzungslimits, menschliche Genehmigung und Audit-Trails, die Unternehmen benötigen, bevor sie Agents gegen Produktionsbudgets einsetzen.

FAQ: x402-natives AgentPay MCP vs. Stripe-Proxy-MCP

Öffentliche MCP-Zahlungs-Repositories beginnen, x402 plus Stripe-Agent-Formulierungen für die Discovery zu verwenden. Behandeln Sie das als Marktsignal, nicht als Beweis dafür, dass jeder Proxy vollständige Ausgabenkontrollen ausgeliefert hat.

Was ist der Hauptunterschied?

AgentPay MCP hält die Zahlungsentscheidung innerhalb der Policy-Grenze des Agents. Der Agent fordert x402_pay an, AgentPay prüft den Genehmigungsstatus und die Spend Policy vor dem Signieren, und der Audit-Trail protokolliert das Tool, den Betrag, den Händler, den Beleg und das Policy-Ergebnis. Ein Stripe-Proxy-Muster platziert normalerweise einen Zahlungs- oder Abrechnungsproxy vor einem nachgelagerten Dienst.

Warum nicht für jeden kostenpflichtigen MCP-Aufruf einen Proxy verwenden?

Ein Proxy kann bei Abrechnung und Kontenaggregation helfen. Er beantwortet nicht automatisch, wer die Ausgabe genehmigt hat, ob der Agent innerhalb seines Task-Budgets geblieben ist oder ob eine Signatur vor der Policy-Genehmigung blockiert wurde. AgentPay MCP behandelt diese Kontrollen vor der Zahlungsausführung.

Welchen Nachweis kann ein Verzeichnis oder Käufer heute prüfen?

• npm: agentpay-mcp@4.1.9 oder neuer

• Glama: https://glama.ai/mcp/servers/up2itnow0822/claw-pay-mcp

• Katalog-Metadaten: glama.json und smithery.yaml

• Installationspfade: npx und Docker

• Introspektion: 27 MCP-Tools, einschließlich x402_pay, check_budget, set_spend_policy und otel_evaluate_spend

Wie ist der Vergleich mit Lightning Wallet MCP?

Lightning Wallet MCP ist ein Bitcoin-Wallet-MCP mit Glama-Badge-Arbeit und x402-Fallback-Positionierung. AgentPay MCP konzentriert sich auf die Governance von x402-Zahlungstools: Genehmigungs-Gates, harte Ausgabelimits, non-custodial lokales Signieren, Verzeichnis-Metadaten und Audit-Zeilen, die an kostenpflichtige Tool-Aufrufe gebunden sind.

Für die vollständige Checkliste siehe x402-natives AgentPay MCP vs. Stripe-Proxy-MCP-Muster.

Für gehostete kostenpflichtige MCP-Gateways verwenden Sie die Checkliste zur Verifizierung von gehosteten x402-Proxy-Käufern vor dem Signieren. Sie prüft payment-required-Header, payTo, Chain, Asset, Ausgabelimit, Genehmigungs-Gate, Audit-Protokoll und Pooled-Token-Lock-in.

Für Ein-Befehl-Käufer-CLI-Vergleiche verwenden Sie die Checkliste zur Parität des AgentPay-Käufer-Flows. Sie verwandelt Discover, Check, Dry-Run, Pay, Ausgabelimit, typisierte Zahlungsfehler, Kontingent-Envelopes, kostenlose Fehlschläge, Idempotenz, MCP-Exposition und Audit in eine Fail-Closed-Fixture. Für kostenpflichtige Worker-Vorlagen verwenden Sie die Checkliste zur Härtung kostenpflichtiger MCP-Gateways, bevor Sie ein Gerüst als produktionsreif behandeln.

Schnellstart

1. Installieren

npm install -g agentpay-mcp

2. Claude Desktop konfigurieren

Zu ~/Library/Application Support/Claude/claude_desktop_config.json hinzufügen:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "CHAIN_ID": "8453"
      }
    }
  }
}

3. Cursor konfigurieren

Zu .cursor/mcp.json oder ~/.cursor/mcp.json hinzufügen:

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "CHAIN_ID": "8453"
      }
    }
  }
}

4. Ausgabelimits festlegen

Sobald es läuft, sagen Sie Ihrem Agent:

Set my spend policy: $1 per transaction, $10 per day, only send to allowlisted addresses.

Oder rufen Sie set_spend_policy direkt auf:

{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.0004",
    "dailyLimitEth": "0.004",
    "allowedRecipients": ["0xapi-provider-address..."]
  }
}

Jetzt kann Ihr Agent für APIs bezahlen — und kann nicht mehr als $1 auf einmal oder $10 pro Tag ausgeben, unabhängig davon, was ihm angewiesen wird.

Human-Approval-Modus (die Standardeinstellung)

Standardmäßig werden Transaktionen über Ihrer Auto-Approval-Schwelle zur menschlichen Prüfung eingereiht. Der Agent kann dies nicht umgehen.

$0.50 USDC request → under $1 threshold → auto-approved → paid → result returned
$5.00 USDC request → over $1 threshold → queued → you get notified → approve or reject

Um eine eingereihte Zahlung zu genehmigen:

{
  "tool": "queue_approval",
  "arguments": {
    "action": "approve",
    "tx_id": "0x..."
  }
}

Um sie abzulehnen:

{
  "tool": "queue_approval",
  "arguments": {
    "action": "cancel",
    "tx_id": "0x..."
  }
}

Der Agent sieht das Ergebnis und entscheidet, was als Nächstes zu tun ist (zwischengespeicherte Daten verwenden, Benutzer fragen, abbrechen).

Value Packs — Drei Produktions-Workflow-Muster

1. Kostenpflichtiger API-Agent

Was er tut: Findet die richtige kostenpflichtige API für einen Datenbedarf, zahlt einmal, speichert das Ergebnis zwischen.

Wann verwenden: Ihr Agent benötigt Daten (Marktdaten, Anreicherung, Geocodierung) und Sie möchten, dass er die Zahlung automatisch abwickelt, anstatt mit einem 402 zu scheitern.

Agent: "I need current options flow data for AAPL"
  │
  ├─ Tries free sources → insufficient data
  ├─ Finds paid API → gets 402 for $0.25 USDC
  ├─ Checks: $0.25 < $1 cap → auto-approved
  ├─ Pays with x402_pay → gets data
  ├─ Caches result at ~/.clawpowers/state/market:AAPL:options
  └─ Returns data + payment receipt

Verwendete Tools: x402_pay, check_spend_limit, get_transaction_history

Beispiel für einen Austausch:

User: Get me the options flow for AAPL for the last 7 days.

Agent: Checking free sources... insufficient. Found paid API at data.example.com.
Cost: $0.25 USDC (under your $1 auto-approve cap). Paying now.
[x402_pay → 200 OK, paid 0.25 USDC, tx: 0xabc...]
Here's the options flow data: [results]
Total cost today: $0.25 of your $10 daily budget.

2. Recherche-Agent

Was er tut: Sammelt zuerst aus kostenlosen Quellen, füllt Lücken mit kostenpflichtigen Daten, erstellt eine strukturierte Ausgabe.

Wann verwenden: Sie benötigen einen umfassenden Recherchebericht und möchten, dass der Agent nur dort Geld ausgibt, wo kostenlose Daten wirklich unzureichend sind.

Agent: "Research competitive landscape for real-time flight tracking APIs"
  │
  ├─ Scrapes free sources (GitHub, HN, docs) → baseline data
  ├─ Identifies gaps: pricing data, SLA guarantees, enterprise contacts
  ├─ Proposes paid lookups totaling $2.75 USDC → presents for approval
  ├─ Human approves
  ├─ Pays for Apollo contact enrichment ($1.50) + Crunchbase data ($1.25)
  └─ Compiles: free data + paid data → structured report

Verwendete Tools: x402_pay, x402_session_start, x402_session_fetch, check_budget

Beispiel für einen Austausch:

User: Research the real-time flight tracking API market. Budget up to $5.

Agent: Starting with free sources... [scrapes 12 sources, builds baseline]
Gaps identified:
  - Vendor pricing (not public for 3 of 5 vendors)
  - Contact info for enterprise sales at FlightAware
  - Recent funding data for two startups

To fill these I'd spend ~$2.75 USDC:
  - Apollo contact enrichment: $1.50
  - Crunchbase firmographics: $1.25

Approve? (y/n)

User: y

Agent: [pays, fetches, compiles]
Report ready. Spent $2.75 of your $5 budget. [structured report attached]

3. Automatisierungs-Agent

Was er tut: Erledigt reale Tasks Ende-zu-Ende und bezahlt für alle Dienste, die unterwegs benötigt werden.

Wann verwenden: Sie möchten einen Agent, der tatsächlich Arbeit abschließen kann — einen Anruf buchen, eine Anreicherungs-Pipeline ausführen, etwas bereitstellen — nicht nur recherchieren.

Agent: "Enrich this list of 50 leads and add to CRM"
  │
  ├─ Processes first 10 free (from existing data)
  ├─ Remaining 40 need enrichment → $0.10/contact = $4.00 USDC
  ├─ Presents plan: 40 contacts × $0.10 = $4.00 total → user approves
  ├─ Runs enrichment in batches of 10 (staying under per-tx cap)
  ├─ Writes enriched data to CRM via API
  └─ Reports: 50 leads enriched, $4.00 spent, 47 successful

Verwendete Tools: x402_pay, x402_session_start, set_spend_policy, get_transaction_history

Enterprise FinOps — Budgetlimit-Vorlagen

Produktions-Agent-Bereitstellungen benötigen Ausgaben-Governance, die die FinOps-Anforderungen von Unternehmen erfüllt. Diese Vorlagen zeigen gängige Muster zur Steuerung von Agent-Ausgaben auf der Infrastrukturebene.

Abteilungsbudgets pro Agent

// Marketing agent — $50/day cap, restricted to approved data vendors
{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.02",
    "dailyLimitEth": "0.02",
    "allowedRecipients": ["0xmarketingVendor1...", "0xmarketingVendor2..."]
  }
}

// Engineering agent — $200/day cap, broader vendor access
{
  "tool": "set_spend_policy",
  "arguments": {
    "perTxCapEth": "0.04",
    "dailyLimitEth": "0.08",
    "allowedRecipients": ["0xcloudProvider...", "0xapiVendor...", "0xdataSource..."]
  }
}

Abgestufte Genehmigungsschwellen

Map your org's approval matrix to agent spending tiers:

Ordnen Sie die Genehmigungsmatrix Ihres Unternehmens den Ausgabenstufen für Agenten zu:

$0 - $1      -> auto-approved (routine API calls)
$1 - $25     -> auto-approved with logging (standard tool usage)
$25 - $100   -> queued for team lead approval via queue_approval
$100+        -> queued for finance team approval

Legen Sie die Obergrenze für automatische Genehmigungen mit set_spend_policy fest (eine prozessinterne Obergrenze, die vom MCP-Server durchgesetzt wird). Transaktionen über den On-Chain-Limits von AgentAccountV2 — die vom Wallet-Besitzer im Vertrag konfiguriert werden — werden über den Smart Contract selbst zur menschlichen Prüfung eingereiht.

Budgetüberwachung für FinOps-Dashboards

Rufen Sie Echtzeit-Ausgabendaten für Ihre FinOps-Tools ab:

// Check remaining budget before starting expensive workflows
{ "tool": "check_budget", "arguments": {} }
// Returns: { "remaining": "142.50 USDC", "spent": "57.50 USDC", "limit": "200.00 USDC" }

// Pull transaction history for cost attribution
{ "tool": "get_transaction_history", "arguments": { "limit": 100 } }
// Each entry includes: merchant, amount, timestamp, tool context — ready for FinOps import

Diese Muster funktionieren mit jeder FinOps-Plattform (CloudHealth, Kubecost, Apptio) — exportieren Sie den Transaktionsverlauf über das MCP-Tool und speisen Sie ihn in Ihre bestehende Kostenzuordnungs-Pipeline ein.

Umgebungsvariablen

# Required
AGENT_PRIVATE_KEY=0x...          # Agent hot wallet key (0x-prefixed hex)
AGENT_WALLET_ADDRESS=0x...       # Deployed AgentAccountV2 contract address

# Optional
CHAIN_ID=8453                    # 8453 = Base Mainnet (default, recommended)
RPC_URL=https://mainnet.base.org # Custom RPC (Alchemy/Infura recommended for production)
SESSION_TTL_SECONDS=3600         # x402 session lifetime (default: 1 hour)
FACTORY_ADDRESS=0x...            # For deploy_wallet and create_escrow
NFT_CONTRACT_ADDRESS=0x...       # For deploy_wallet

# Optional — otel_register_budget_policy circuit breaker
# Comma-separated hosts whose private/loopback/link-local kill-callback URL is
# explicitly permitted. Empty by default: a killCallbackUrl pointing into
# private space is dropped (with a warning) and never POSTed to, though the
# budget policy's spend cap is always registered and enforced regardless.
# Set this only if your circuit-breaker webhook genuinely lives in-VPC.
AGENTPAY_KILL_CALLBACK_ALLOWED_HOSTS=orchestrator.svc.internal

SSRF-Limits für Kill-Callback. Eine killCallbackUrl muss http(s) sein, darf keine Zugangsdaten enthalten und darf keine private, Loopback-, Link-Local- oder anderweitig nicht global routbare Adresse benennen (RFC1918, CGNAT, Multicast, reservierte Bereiche, IETF-Protokollzuweisungen, Benchmarking- und Dokumentationsbereiche sowie die IPv6-Äquivalente und jede IPv4-in-IPv6-Übergangsform). Hostnamen werden unmittelbar vor dem Auslösen des Callbacks aufgelöst und erneut anhand derselben Regeln geprüft. Eine einzige feste 10s-Frist deckt DNS-Auflösung und POST zusammen ab, sodass ein Resolver, der nie antwortet, die Span-Auswertung nicht offenhalten kann.

Eine Lücke ist nicht geschlossen: Die Verbindung ist nicht an die Adresse gebunden, die validiert wurde. Ein Resolver, der zum Prüfzeitpunkt eine öffentliche Adresse und zum Verbindungszeitpunkt eine private Adresse liefert (DNS-Rebinding), kann daher weiterhin erreicht werden. Um sie zu schließen, muss dieser Aufruf vom globalen fetch auf node:http/node:https mit einem fixierten lookup umgestellt werden, was separat verfolgt wird. Wenn Sie heute eine harte Garantie benötigen, setzen Sie dem Webhook eine Egress-Allowlist auf Netzwerkebene vor. Nicht zugestellte Callbacks melden nur ok=false mit einem einzigen allgemeinen Grund — der HTTP-Status und der konkrete Fehler werden niemals an den Aufrufer zurückgegeben, sondern nur serverseitig protokolliert (nur der Ursprung, niemals der Callback-Pfad oder die Query).

Alle 23 Tools

Zahlungen & 402-Flow

Wallet & Ausgabenkontrolle

Token-Operationen

DeFi

Identität & Vertrauen

Wichtige Tool-Beispiele

x402_pay — Das Kern-Tool

// Request
{
  "tool": "x402_pay",
  "arguments": {
    "url": "https://api.example.com/premium-data",
    "max_payment_eth": "0.0002"
  }
}

// Response
{ "status": 200, "body": "{ ... }" }

Wenn die Kosten max_payment_eth überschreiten, gibt das Tool einen Fehler zurück, bevor eine Zahlung erfolgt — keine Überraschungskosten.

x402_session_start — Einmal zahlen für mehrere Aufrufe

// Request
{
  "tool": "x402_session_start",
  "arguments": {
    "endpoint": "https://api.example.com/",
    "ttl_seconds": 3600,
    "label": "market-data-session"
  }
}

// Response
{ "session_id": "sess_abc123", "token": "eyJ...", "expires_at": 1741000000 }

// Subsequent calls — no new payment
{
  "tool": "x402_session_fetch",
  "arguments": {
    "url": "https://api.example.com/stocks/AAPL",
    "session_id": "sess_abc123"
  }
}

check_budget — Vor der Schleife Bescheid wissen

// Request — check before starting an expensive loop
{ "tool": "check_budget", "arguments": {} }

// Response
{
  "remaining": "7.50 USDC",
  "spent": "2.50 USDC",
  "limit": "10.00 USDC",
  "periodEnds": "2026-03-24T00:00:00Z"
}

Unterstützte Chains

Sicherheitsmodell

Nicht-verwahrend: Der Agent signiert alle Transaktionen lokal mit seinem privaten Schlüssel. Kein Dritter hält oder validiert Schlüssel.

On-Chain-Durchsetzung (AgentAccountV2-Limits, vom Wallet-Besitzer im Vertrag konfiguriert):

• Limits pro Transaktion — Transaktionen über dem Limit werden über queue_approval zur menschlichen Genehmigung eingereiht

• Tageslimits — die Gesamtausgaben werden vom AgentAccountV2-Smart-Contract durchgesetzt

Prozessinterne Richtlinie (set_spend_policy — im MCP-Server durchgesetzt, nicht on-chain):

• Empfänger-Allowlists, Limits pro Transaktion und Tageslimits — eine praktische Schutzmaßnahme, die von einem kompromittierten Serverprozess umgangen werden kann. Die genauen Kontrollgrenzen finden Sie in docs/security-posture.md.

Rollentrennung:
Der Signaturschlüssel des Agenten (AGENT_PRIVATE_KEY) kann nur innerhalb der vom Wallet-Besitzer festgelegten Limits Transaktionen ausführen. Selbst wenn der Schlüssel des Agenten geleakt wird oder der Agent kompromittiert ist, kann ein Angreifer bis zum nächsten Reset nur bis zur konfigurierten Obergrenze ausgeben.

x402-Sitzungen:
Sitzungstokens sind ECDSA-signierte Claims. Jeder x402-V2-Server kann sie unabhängig verifizieren — kein zentraler Sitzungsspeicher erforderlich.

Minimale Abhängigkeiten:
AgentPay MCP hat keinerlei LiteLLM-Abhängigkeit. Der gesamte Server läuft auf viem (Ethereum-Client), @modelcontextprotocol/sdk und einigen wenigen prüfbaren Paketen — keine schwergewichtigen LLM-Routing-Ebenen im Abhängigkeitsbaum. Das ist wichtig: Am 24. März 2026 wurden LiteLLM-Versionen 1.82.7 und 1.82.8 auf PyPI im Rahmen eines Supply-Chain-Angriffs, der auf KI-Agenten-Infrastruktur abzielte, als kompromittiert bestätigt. Jeder MCP-Server, der von LiteLLM abhängt (direkt oder transitiv), war exponiert. AgentPay MCP war es nicht — denn Zahlungsinfrastruktur sollte die kleinstmögliche Angriffsfläche haben.

agentpay-mcp unterstützt bereits mehrere Zahlungswege

Die Zahlungslandschaft für Agenten hat sich gerade aufgespalten: Coinbases x402 (offen, erlaubnisfrei, on-chain) vs. Stripes MPP (erlaubnisbasiert, Tempo-basiert, USDC). Entwickler, die Produktionsagenten bauen, stehen vor einer Wahl — oder sie verwenden agentpay-mcp, das bereits über beiden sitzt.

agentpay-mcp ist von Natur aus protokollneutral:

Warum das wichtig ist: Weder x402 noch MPP bringt Ausgaben-Governance mit. x402-Wallets sind standardmäßig unbegrenzt. MPP bietet von Menschen festgelegte Dashboard-Limits, aber keine programmatische Durchsetzung pro Sitzung oder pro Aufgabe. agentpay-mcp bietet den Budget-Schutzschalter, Genehmigungsworkflows und den Audit-Pfad über beiden — unabhängig davon, welcher Zahlungsweg die Transaktion abwickelt.

Das ist kein Wrapper um ein einzelnes Protokoll. Es ist eine Governance-Ebene mit einer bewussten Trennung zwischen Policy (wer hat es genehmigt, wie hoch ist das Budget, sollte ein Mensch das prüfen) und Settlement (welche Blockchain oder welches Zahlungsnetzwerk bewegt das Geld). Genau diese Trennung macht agentpay-mcp rail-neutral — und positioniert es als Governance-Standard, während sich der Protokollkrieg entfaltet.

Funktioniert mit AWS AgentCore

AWS AgentCore bietet Enterprise-taugliches Agentenhosting mit Cedar-basierter Richtliniendurchsetzung für die Zugriffskontrolle. Cedar-Richtlinien beantworten: „Darf dieser Agent diese API aufrufen?“ und „Kann dieser Agent auf diese Ressource zugreifen?“

Was Cedar NICHT bietet: Ausgabelimits. Es gibt kein Cedar-Primitiv für „dieser Agent kann pro Sitzung höchstens $50 ausgeben“ oder „Agent anhalten, wenn die kumulierten Ausgaben heute $200 überschreiten.“ Zugriffskontrolle und Budget-Governance sind unterschiedliche Probleme.

agentpay-mcp ergänzt AgentCore um den Budget-Schutzschalter:

Bereitstellungsmuster: AgentCore führt den Agenten aus, wobei Cedar-Richtlinien den Toolzugriff steuern. agentpay-mcp läuft als MCP-Server im Tool-Set des Agenten und setzt bei jeder Zahlungsaktion Ausgabengrenzen durch. Cedar sagt: „Du darfst diese kostenpflichtige API aufrufen.“ agentpay-mcp sagt: „Du darfst bei diesem Aufruf bis zu $5 ausgeben.“

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x...",
        "MAX_TRANSACTION_USDC": "5.00",
        "DAILY_LIMIT_USDC": "50.00"
      }
    }
  }
}

Für Unternehmen, die Agenten auf AgentCore betreiben: Cedar beantwortet die „Kann es?“-Frage. agentpay-mcp beantwortet die „Sollte es so viel ausgeben?“-Frage. Zusammen stellen sie den Zugriffs- und Budget-Governance-Stack bereit, den Produktionsagenten-Bereitstellungen erfordern.

Wettbewerbspositionierung

Der einfachste Weg, es zu verstehen: ACP (Stripe) verwaltet, was Agents VERKAUFEN, agentpay-mcp verwaltet, was Agents KAUFEN.

Stripe MCP vs. agentpay-mcp

Entwickler fragen oft: „Handhabt Stripe MCP nicht bereits Agentenzahlungen?" Die Antwort lautet, dass sie unterschiedliche Probleme auf unterschiedlichen Ebenen lösen:

Stripe MCP ist ein Händler-Tool – es hilft Unternehmen, Kunden über Agent-Schnittstellen Zahlungen abzunehmen. Denken Sie an „dieses Produkt kaufen" oder „diesen Plan abonnieren".

agentpay-mcp ist ein Beschaffungstool für Agents – es ermöglicht Agents, für die APIs und Tools zu zahlen, die sie für ihre Arbeit benötigen. Denken Sie an „auf diesen Premium-Datendienst zugreifen" oder „diese Rechenressource nutzen".

Die meisten Produktions-Agents werden beide Ebenen benötigen: Stripe MCP für den nutzerseitigen Handel, agentpay-mcp für die eigenen Tool-Kosten des Agents. Sie ergänzen sich, statt zu konkurrieren.

MCP-2026-Konformität

AgentPay MCP erfüllt die aufkommenden MCP-Sicherheitsstandards für 2026, einschließlich der CoSAI-Bedrohungskategorien (Coalition for Secure AI) und der OAuth-2.1-Anforderungen.

Dokumentation der Sicherheitslage: Siehe docs/security-posture.md für die vollständige Konformitätsmatrix mit:

• CoSAI T9 (Finanzbetrug) – Mehrschichtige Ausgabenkontrollen: eine prozessinterne Ausgabenrichtlinie (set_spend_policy, im MCP-Serverprozess durchgesetzt – nicht on-chain) sowie On-Chain-AgentAccountV2-Limits und Genehmigungswarteschlangen, die vom Wallet-Besitzer konfiguriert werden

• CoSAI T10 (Identitätsspoofing) – ERC-8004-Agentenidentitätsprüfung + nicht-verwahrende Schlüsselverwaltung verhindern identitätsbasierte Angriffe

• OAuth 2.1 + PKCE – Die MCP-Serverauthentifizierung unterstützt OAuth 2.1 mit PKCE für die Integration in das Enterprise-SSO (Azure AD, Okta)

• Audit-Protokollierung – On-Chain-Ereignishistorie von AgentAccountV2 über get_transaction_history (Ausführungen, eingereihte Transaktionen, Genehmigungen, Richtlinienaktualisierungen); es gibt kein Protokoll pro Tool-Aufruf – siehe das Sicherheitsdokument für genau das, was aufgezeichnet wird und was nicht

Für Enterprise-Sicherheitsteams, die MCP-Server evaluieren: Das Dokument zur Sicherheitslage liefert das Artefakt, das Ihr Auditprozess benötigt.

Architektur

┌─────────────────────────────────────────┐
│  AI Agent (Claude / Cursor / Windsurf)  │
└────────────────┬────────────────────────┘
                 │  MCP (stdio / SSE)
┌────────────────▼────────────────────────┐
│           AgentPay MCP Server           │
│  ┌────────────┐  ┌────────────────────┐ │
│  │  23 Tools  │  │  Session Manager   │ │
│  └─────┬──────┘  └────────────────────┘ │
│        │                                │
│  ┌─────▼──────────────────────────────┐ │
│  │       agentwallet-sdk v6.0.0       │ │
│  │  TokenRegistry  SwapModule         │ │
│  │  BridgeModule   ERC8004Client      │ │
│  └─────┬──────────────────────────────┘ │
└────────┼────────────────────────────────┘
         │  viem + RPC
┌────────▼────────────────────────────────┐
│  AgentAccountV2 Smart Contract          │
│  SpendingPolicy  ·  Tx Queue            │
│  (12 chains — Base, ETH, ARB, OP, ...)  │
└─────────────────────────────────────────┘

Transport: standardmäßig stdio (Claude Desktop, Cursor, Windsurf). SSE für entfernte Bereitstellungen verfügbar.

Mitwirken

git clone https://github.com/up2itnow0822/agentpay-mcp
cd agentpay-mcp
npm install
npm run build
npm test

Patenthinweis

Patent angemeldet – Vorläufige USPTO-Anmeldung eingereicht im März 2026: „Non-Custodial Multi-Chain Financial Infrastructure System for Autonomous AI Agents."

Wir unterstützen den offenen x402-Standard. Unsere Anmeldung ist defensiv – sie soll eine feindselige Monopolisierung offener Zahlungsinfrastrukturen verhindern, nicht Entwickler einschränken, die offene Standards nutzen.

Interoperabilität mit Vercel x402-mcp

agentpay-mcp ist vollständig kompatibel mit Vercels x402-mcp-Paket. Wenn Sie Vercels paidTool() verwenden, um MCP-Tools zu monetarisieren, fungiert agentpay-mcp als clientseitige Zahlungsebene – Ihr Agent bezahlt x402-Rechnungen von paidTool()-Endpunkten automatisch über x402_pay.

Was agentpay-mcp zusätzlich zu x402-mcp bietet:

• Multi-Rail-Zahlungen – Routing über x402 (USDC on-chain) oder Stripe Machine Payments Protocol (Fiat), abhängig vom Händler

• Ausgabenverwaltung – Limits pro Transaktion, Tageslimits und menschliche Genehmigungswarteschlangen, die paidTool()-Endpunkte nicht clientseitig durchsetzen

• Multi-Chain-x402-v2 – Bezahlen auf Base, Solana oder Polygon (x402 v2 unterstützt alle drei Netzwerke nativ)

Verwenden Sie Vercel x402-mcp serverseitig, um Ihre Tools zu monetarisieren. Verwenden Sie agentpay-mcp clientseitig, um sicher für Tools zu bezahlen.

Circle Nanopayments – Abrechnung ohne Gas

agentpay-mcp unterstützt Circle Nanopayments als Abrechnungsoption für x402-v2-Zahlungen. Nanopayments ermöglichen gasfreie USDC-Transfers unter einem Cent, indem kleine Zahlungen zu einzelnen On-Chain-Abrechnungen gebündelt werden.

So funktioniert es mit agentpay-mcp:

• Der Agent tätigt wie gewohnt eine x402-Zahlung über x402_pay

• Wenn der x402-v2-Server Circle Nanopayments unterstützt, erfolgt die Abrechnung gasfrei

• Zahlungen unter einem Cent (0,001 $, 0,0001 $) werden für die API-Bepreisung pro Aufruf wirtschaftlich tragfähig

• Cross-Chain-Unterstützung über Circle's Gateway – funktioniert auf jeder EVM-Chain

Dies ist besonders nützlich für hochfrequente Agent-Workflows, bei denen die Gaskosten andernfalls den Zahlungsbetrag übersteigen würden. Siehe Circle's Ankündigung für Protokolldetails.

x402-Ökosystem – 75 Mio.+ Transaktionen, native Cloudflare-Unterstützung

agentpay-mcp basiert auf dem x402-HTTP-Zahlungsstandard, der inzwischen über 75 Millionen Transaktionen auf Base-Mainnet verarbeitet hat – hauptsächlich über Coinbase Agentic Wallets und Entwickler-Integrationen.

Cloudflare hat native x402-Unterstützung zu seinem Agents SDK und der MCP-Serverlaufzeit hinzugefügt, was bedeutet, dass jeder auf Cloudflare Workers gehostete Agent nun nativ x402-Zahlungen tätigen kann. Google, Circle und Stripe integrieren x402 aktiv in ihre Agent-Ökosysteme.

agentpay-mcp ist die Open-Source-Governance-Ebene auf dieser Infrastruktur: Während x402 das Zahlungsprotokoll übernimmt, fügt agentpay-mcp die Vertrauenskontrollen hinzu, die Produktions-Agents benötigen – HITL-Genehmigungswarteschlangen, Ausgabenobergrenzen, Empfänger-Whitelists und On-Chain-Audit-Trails.

Kompatibilität mit der OpenAI Delegated Payment Spec

OpenAI hat eine Delegated Payment Spec veröffentlicht, die definiert, wie KI-Agents Zahlungen im Namen von Nutzern abwickeln: ein eingeschränktes Token mit einem Ausgabenlimit, kompatibel mit Stripe Scoped Payment Tokens (SPTs). Dies ist die Vorläuferarchitektur für native Zahlungsfunktionen im Agents SDK von OpenAI.

Das Ausgabenlimit-Modell von agentpay-mcp entspricht direkt dem Muster der Delegated Payment Spec:

Das Kernmuster ist identisch: Mensch genehmigt ein Budget → Agent führt innerhalb dieses Budgets aus → alle Aktivitäten sind prüfbar. Der Unterschied liegt in der Abrechnungsebene: Die OpenAI-Spec zielt auf Stripe-SPTs (Fiat-Infrastruktur), während agentpay-mcp on-chain abrechnet (USDC/ETH auf Base, Arbitrum und 8 weiteren EVM-Chains).

Für Entwickler, die Workflows mit dem OpenAI Agents SDK erstellen und On-Chain-Abrechnung oder Multi-Rail-Zahlungsausführung benötigen, dient agentpay-mcp als MCP-Zahlungstool, das das Muster der Delegated Payment Spec mit On-Chain-Durchsetzung statt Vertrauen auf Anwendungsebene umsetzt.

{
  "mcpServers": {
    "agentpay": {
      "command": "npx",
      "args": ["agentpay-mcp"],
      "env": {
        "AGENT_PRIVATE_KEY": "0x...",
        "AGENT_WALLET_ADDRESS": "0x..."
      }
    }
  }
}

Fügen Sie diesen MCP-Server über eine MCP-Brücke zu jedem OpenAI-Agents-SDK-Workflow hinzu. Der Agent erhält x402_pay, check_budget und set_spend_policy – dasselbe Muster aus eingeschränktem Token und Ausgabenlimit. Beachten Sie, dass set_spend_policy im MCP-Serverprozess durchgesetzt wird; die Smart-Contract-Durchsetzung erfolgt über die On-Chain-AgentAccountV2-Limits, die der Wallet-Besitzer im Vertrag konfiguriert (siehe docs/security-posture.md).

Kompatibilität mit Google AP2

agentpay-mcp ergänzt Googles Agent2Agent Payment (AP2)-Protokoll. AP2 – unterstützt von über 60 Organisationen, darunter Visa, Mastercard und PayPal – übernimmt die Autorisierung von Agentenzahlungen: Es stellt sicher, dass eine Zahlungsanfrage legitim ist. agentpay-mcp arbeitet auf der Governance-Ebene über AP2 und fügt Budgetobergrenzen pro Agent, tägliche Ausgabenlimits und Schwellenwerte für menschliche Genehmigungen hinzu, die AP2 bewusst als Out-of-Band ausklammert. Für Unternehmen, die Agents über mehrere Zahlungswege hinweg einsetzen, bietet agentpay-mcp die einheitliche Ausgabenverwaltung, die kein einzelnes Protokoll abdeckt.

EU-AI-Act-Konformität

Durchsetzungsfrist: 2. August 2026. KI-Systeme, die Finanztransaktionen ausführen oder erleichtern, werden gemäß Anhang III des EU AI Act als Hochrisiko eingestuft. Eine Hochrisiko-Einstufung erfordert:

• ✅ Mechanismen zur menschlichen Aufsicht – verpflichtende menschliche Überprüfung und Überschreibungsmöglichkeit

• ✅ Transparenz und Erklärbarkeit – prüfbare Transaktionsaufzeichnungen

• ✅ Zugriffskontrollen – Ausgabenlimits, die vom Agent nicht umgangen werden können

• ✅ Technische Dokumentation – Unterstützung der Konformitätsbewertung

agentpay-mcp erfüllt alle vier Anforderungen sofort einsatzbereit:

Europäische Unternehmen, die Agent-Systeme einsetzen, die Zahlungen berühren, haben ~150 Tage Zeit, um konforme menschliche Aufsichts- und Auditkontrollen zu implementieren. agentpay-mcp ist der schnellste Weg zur EU-AI-Act-Konformität für MCP-kompatible Agent-Bereitstellungen.

Bußgelder bei Nichteinhaltung: Bis zu 35 Mio. € oder 7 % des weltweiten Jahresumsatzes. Deutschland hat seinen nationalen Durchsetzungsgesetzentwurf im Februar 2026 veröffentlicht.

Lizenz

MIT © AI Agent Economy

Entwickelt von AI Agent Economy – Infrastruktur für Agent-Workflows in der Produktion.