Z-ZERO MCP
Payment infrastructure MCP server enabling AI agents to make gasless USDC payments on Base and JIT single-use virtual card checkouts, with zero-trust card handling, merchant checkout hints, and signed receipts.
README
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.
- π³ 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_hintsserves platform-specific checkout playbooks (Shopify, Etsy, WooCommerceβ¦). - βοΈ Signed intent + signed receipt β the card is bound to a signed statement of what it is for, and every confirmed purchase returns a signed receipt with a diff against that intent. The agent can prove a purchase instead of claiming one (
verify_receipt, public verify page). - π 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, card_alias) β
β βββββββββββββββββββββββΆβ β
β ββββ temp_auth token βββ€ (1-hour TTL) β
β β β β
β β execute_payment(token, checkout_url) β
β βββββββββββββββββββββββΆβ β
β β Playwright auto-fills card form, β
β β burns token after single use π₯ β
β ββββββ β
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_checkoutdetects a crypto-native checkout (EIP-681), it skips the card flow entirely and settles as a gasless USDC transfer on Base β see above.
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
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(mode0600). 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/credentialsfirst; theZ_ZERO_API_KEYenv 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)
| Tool | Description |
|---|---|
list_cards |
List all virtual card aliases and balances |
check_balance |
Check spendable USD balance for a card alias |
get_deposit_addresses |
Get your Base deposit address to top up with USDC (stablecoin on Base) |
set_api_key |
Activate a new Passport Key instantly, no restart needed |
show_api_key_status |
Check if a Passport Key is currently loaded (prefix only) |
Group 2 β Manual 4-Step Payment (Active)
| Tool | Description |
|---|---|
request_payment_token |
Issue a JIT single-use virtual-card token for a specific amount (1hr TTL). Pass cart + ship_to and the card is bound to a signed intent |
execute_payment |
Auto-fill checkout form using a payment token via Playwright. Returns a signed receipt on confirmed payments |
cancel_payment_token |
Cancel an unused token and refund to wallet |
request_human_approval |
Pause and request human confirmation before proceeding |
Group 3 β Smart Autopilot
| Tool | Description |
|---|---|
auto_pay_checkout |
Fully autonomous checkout β auto-detects Web3 or Fiat and completes payment |
get_merchant_hints |
Fetch platform-specific checkout playbook (pre-steps + selectors) from Knowledge Base |
report_checkout_fail |
Report a failed checkout with a structured failure_class (14-class enum) β feeds the self-healing loop |
verify_receipt |
Verify a signed receipt by id β prove a purchase happened instead of claiming it |
π Note: Version checking is handled automatically in each API call. No separate tool needed.
Agent primitives (v1.7.0)
Three things an agent can do here that it cannot do with a normal virtual card.
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"
})
Z-ZERO signs that statement (EIP-191) and binds it to the card. The user gets cryptographic proof of what this card was authorized to buy β not just how much it could spend. 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. Signed receipt β prove the purchase, don't claim it
On a confirmed payment you get back:
"signed_receipt": {
"receipt_id": "8ea36791-β¦",
"receipt_hash": "0xβ¦",
"match": { "total": "over", "domain": "ok" },
"diff": [{ "field": "total", "expected": 44.00, "observed": 46.75 }],
"verify_url": "https://z-zero.xyz/receipt/8ea36791-β¦"
}
diff is the part that matters: it is what the merchant actually did versus what
was authorized. Share verify_url with the user β the page is public and anyone
can check it. Verification is three checks: the signature is valid, the signer is
Z-ZERO, and the fields shown still hash to what was signed (so editing the record
afterwards is detectable, including by us).
What a valid receipt does and does not prove. It proves the record is signed by
Z-ZERO and unaltered. It does not by itself prove the merchant charged what the
receipt says β most fields start life as the agent's reading of a web page. Every
receipt therefore carries provenance per field: zzero_issued (the limit we set),
issuer_captured (confirmed by the card issuer's capture webhook β settlement
evidence), agent_reported (unverified), human_verified. Until the capture webhook
lands, this is a signed execution receipt, not settlement proof, and it says so.
3. Structured failure classes β every failure teaches the network
report_checkout_fail takes a fixed enum, not free text:
card_declined_issuer Β· card_declined_bin_block Β· avs_mismatch Β· 3ds_required Β·
bot_detected Β· form_changed Β· price_changed Β· out_of_stock Β·
shipping_unsupported Β· login_required Β· timeout Β· outcome_unconfirmed Β·
intent_mismatch Β· unknown
Failed runs are also labeled automatically from the browser outcome, so the network learns even when nobody remembers to report. Card numbers are redacted at capture β they never reach a log, screenshot or DOM dump.
REST API Reference
The Z-ZERO backend is hosted at https://z-zero.xyz. All endpoints require a Bearer token using your Passport Key.
β οΈ Use the MCP tools above instead of calling REST directly. If you must call REST, use the exact paths below.
GET /api/tokens/cards
Returns your card list, balance, and deposit addresses.
curl -X GET "https://z-zero.xyz/api/tokens/cards" \
-H "Authorization: Bearer zk_live_your_key"
Aliases (also work):
GET /api/v1/cardsβ for agents that guess REST-style paths
POST /api/tokens/issue
Issue a JIT payment token.
POST /api/tokens/resolve
Resolve a token to card data (server-side only).
POST /api/tokens/burn
Burn a used token.
POST /api/tokens/cancel
Cancel an unused token (refunds balance).
Troubleshooting
"Z_ZERO_API_KEY is missing"
- Go to z-zero.xyz/dashboard/agents
- Copy your Passport Key (starts with
zk_live_) - Add it to your config as
Z_ZERO_API_KEY - Restart Claude Desktop / Cursor
"Invalid API Key" (401)
- Double-check you copied the full key (e.g.
zk_live_c0g3l) - Make sure there are no extra spaces or line breaks
"404 Not Found" on /api/v1/cards
- This is a legacy path alias β it should now work. If not, use
/api/tokens/cardsdirectly.
Security: the key you paste is never kept β it rotates the moment your agent first connects, and the fresh key lives only in a local owner-only file (~/.z-zero/credentials, mode 0600), never in any LLM conversation. Card data exists only in volatile RAM during execution.
Recommended Servers
playwright-mcp
A Model Context Protocol server that enables LLMs to interact with web pages through structured accessibility snapshots without requiring vision models or screenshots.
Magic Component Platform (MCP)
An AI-powered tool that generates modern UI components from natural language descriptions, integrating with popular IDEs to streamline UI development workflow.
Audiense Insights MCP Server
Enables interaction with Audiense Insights accounts via the Model Context Protocol, facilitating the extraction and analysis of marketing insights and audience data including demographics, behavior, and influencer engagement.
VeyraX MCP
Single MCP tool to connect all your favorite tools: Gmail, Calendar and 40 more.
graphlit-mcp-server
The Model Context Protocol (MCP) Server enables integration between MCP clients and the Graphlit service. Ingest anything from Slack to Gmail to podcast feeds, in addition to web crawling, into a Graphlit project - and then retrieve relevant contents from the MCP client.
Kagi MCP Server
An MCP server that integrates Kagi search capabilities with Claude AI, enabling Claude to perform real-time web searches when answering questions that require up-to-date information.
Neon Database
MCP server for interacting with Neon Management API and databases
E2B
Using MCP to run code via e2b.
Exa Search
A Model Context Protocol (MCP) server lets AI assistants like Claude use the Exa AI Search API for web searches. This setup allows AI models to get real-time web information in a safe and controlled way.
Qdrant Server
This repository is an example of how to create a MCP server for Qdrant, a vector search engine.