Z Zero MCP

Z-ZERO MCP — Payment Infrastructure for Agentic Commerce (USDC on Base, gasless)

AI Agents today can plan, reason, and code — but they are financially blind. They cannot hold money, make payments, or prove their trustworthiness. Every purchase still requires a human to copy-paste a credit card number.

Z-ZERO fixes that. One MCP server gives your agent (Claude, Cursor, any MCP-compatible client) two payment rails — gasless USDC on Base for crypto-native checkouts, and JIT single-use virtual cards for the 99% of the web that only takes cards — while the model never sees a real card number.

npx z-zero-mcp-server

What makes it different:

• 🔐 Zero-trust by design — the AI never sees PAN, CVV, or expiry. Card data exists only in RAM, injected via Playwright at the last step, then wiped.
• ⛽ Gasless USDC on Base — auto-detects crypto checkout (EIP-681) and settles as a gasless USDC transfer sponsored by Coinbase Paymaster. The agent holds only USDC — no ETH, no gas UX. Opt-in: off unless you set Z_ZERO_ENABLE_WEB3_PAY=1, because an on-chain send to an address read off a web page cannot be reversed.
• 💳 JIT single-use virtual cards — amount-locked, 1-hour TTL, burned after a single use. Fiat fallback for the rest of the web.
• 🧠 Smart Routing + checkout intelligence — get_merchant_hints serves platform-specific checkout playbooks (Shopify, Etsy, WooCommerce…).
• ✍️ Linked purpose + outcome — the server signs the criteria the agent records at issuance. Before checkout, execute_payment hands those criteria back and requires a second call with go or pause; a confirmed purchase seals the answer into the signed receipt. The record is inspectable without pretending the platform judged whether the agent told the truth.
• 🔄 Structured failure labels — failed checkouts are labeled with a fixed 14-class failure_class (automatically, not only when an agent remembers to report) and stored as evidence for the merchant knowledge base. Facts are promoted into shared hints only after a later outcome or review verifies them.

---

Live on Base Mainnet

• ✅ Proof — real gasless USDC transfer on Base mainnet: 0xdfd1f2f8…5d7a
• Onboarding is just "deposit USDC" — no seed phrases in the agent, no native gas token, no exchange account.

---

How It Works

 User            AI Agent              MCP Tools              Z-ZERO API

│ │ │ │ │ "Buy me this │ │ │ │ Shopify item" │ │ │ ├─────────────────▶│ │ │ │ │ read mcp://resources/sop (MANDATORY) │ │ ├─────────────────────▶│ │ │ │◀── platform rules ───┤ │ │ │ + payment SOP │ │ │ │ │ │ │ │ get_merchant_hints("_platform_shopify") │ │ ├─────────────────────▶│ GET /checkout-hints │ │ │ ├─────────────────────▶│ │ │◀── pre_steps+notes ──┤◀──── hints data ─────┤ │ │ │ │ │ │ (fills shipping form, reaches payment page) │ │ │ │ │ │ │ request_payment_token(amount, cart, criteria)│ │ ├─────────────────────▶│ │ │ │◀── temp_auth token ──┤ (1-hour TTL) │ │ │ │ │ │ │ execute_payment(token, checkout_url) │ │ ├─────────────────────▶│ │ │ │◀── purpose_check ────┤ (nothing charged) │ │ │ compare locked criteria with final page │ │ │ │ │ │ │ execute_payment(..., recheck: go | pause) │ │ ├─────────────────────▶│ │ │ │ pause → no card is filled │ │ │ go → Playwright fills + submits, │ │ │ then burns token if confirmed 🔥 │ │ │◀──── ✅ success ─────┤ │ │ "Done! Your item │ │ │ │ is ordered." │ │ │ │◀─────────────────┤ │ │

*The AI agent never touches card data — it only handles single-use tokens. Real card details are injected by Playwright at the last step and wiped from RAM.*

Crypto checkout branch: when auto_pay_checkout detects a crypto-native checkout (EIP-681), it skips the card flow entirely and settles as a gasless USDC transfer on Base — see above. Off by default; enable with Z_ZERO_ENABLE_WEB3_PAY=1.

---

Why Z-ZERO

Z-ZERO is not a checkout bot — it's payment infrastructure for the agentic-commerce era (agentic transactions are projected to reach $1.5T by 2030 — Juniper Research).

Today, the web is built for humans: agents must fill forms and click buttons, and every purchase still needs a human's card. Z-ZERO solves that now — JIT single-use virtual cards + gasless USDC on Base, with card data isolated from the model. Tomorrow, agent payments become a standardized protocol — and what we build along the way is the long-term value:

• Shared checkout intelligence — every transaction (and every failure) makes the network smarter.
• An open standard for agent payments — any agent platform plugs in via MCP; any rail (cards, USDC, x402) can be added.
• KYA — Know Your Agent — verifiable agent reputation. The question isn't "can this agent pay?" but "should you trust it to?"

📖 Full vision & architecture: The Z-Zero Whitebook

---

Quick Install (Recommended)

npx z-zero-mcp-server

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{

"mcpServers": { "z-zero": { "command": "npx", "args": ["-y", "z-zero-mcp-server@latest"], "env": { "Z_ZERO_API_KEY": "zk_live_your_passport_key_here" } } } }

Get your Passport Key at: [z-zero.xyz/dashboard/agents](https://z-zero.xyz/dashboard/agents)

---

Security: rotate-on-connect (v1.5.0+)

The key you copy from the dashboard (or paste into a chat) is only a one-time bootstrap ticket. The moment your agent connects with it, the MCP server silently swaps it for a fresh key:

• The fresh key travels server → MCP process → disk and is stored in ~/.z-zero/credentials (mode 0600). It never appears in any LLM conversation, tool result, or config file.
• The pasted key is dead within seconds — a copy living in a chat transcript, clipboard, or screenshot can no longer be used by anyone.
• On startup the MCP loads the key from ~/.z-zero/credentials first; the Z_ZERO_API_KEY env var is only a bootstrap fallback.

One key = one machine. All agents on the same machine (Claude Desktop, Claude Code, Cursor, …) share the same MCP install and the same credentials file — install once, every agent can pay. Connecting a *different* machine with a copied key rotates it, which instantly disconnects the original machine. That is deliberate: it blocks key sharing and doubles as an intrusion alarm — if your agent suddenly fails auth, someone else used your key; go to the dashboard and revoke.

Older self-hosted backends without the rotate endpoint keep working — the pasted key simply stays active as before.

---

Requirements

• Node.js v18+ — nodejs.org
• Passport Key — starts with zk_live_, get it from the dashboard above

---

Available MCP Tools

Group 1 — Wallet Config (Passive)

Group 2 — Manual Card Payment (Active)

Group 3 — Smart Autopilot

📖 Note: Version checking is handled automatically in each API call. No separate tool needed.

---

Agent primitives (v1.9.0)

Four linked records and controls an agent can use here that it cannot get from a normal virtual card alone.

1. Signed intent — the card knows what it is for

Pass the cart when you request a token:

request_payment_token({

card_alias: "Card_01", amount: 44.00, merchant: "etsy.com", cart: [{ title: "Ceramic mug — matte white", qty: 2, unit_price: 18.50 }], ship_to: "12 Nguyen Hue, District 1, Ho Chi Minh City, VN", criteria: { source: "user_described", items: [ { key: "item", stated: "two matte-white ceramic mugs" }, { key: "max_total", stated: "no more than $44 delivered" } ] } })

Z-ZERO signs that statement (EIP-191) during issuance. It is a tamper-evident record of the criteria the agent supplied as the owner's instruction — not an independent proof that the human personally approved every line. The shipping address is stored as a hash, never raw.

Before you request a token, compare the checkout page with what the user actually asked for — same items, same quantity, same variant, same destination. A mismatch you catch there costs nothing. After the token, it costs a card.

2. Purpose check — read first, then declare go or pause

execute_payment is deliberately a two-call tool:

// Call 1 — omit recheck. No browser, PAN, or charge.

execute_payment({ token, checkout_url, actual_amount: 44.00 }) // → { status: "purpose_check", nothing_charged: true, owner_asked_for: ... }

// Call 2 — describe the final page and make an explicit decision. execute