Z-ZERO MCP provides payment infrastructure for AI agents, enabling autonomous purchases via gasless USDC on Base and JIT single-use virtual cards for fiat transactions, while never exposing real card data to the model.
Wallet & Account Management:list_cards – view virtual card aliases and balances; check_balance – check spendable USD balance; get_deposit_addresses – retrieve Base network deposit addresses for USDC top-ups; set_api_key – activate a new Passport Key with key rotation; show_api_key_status – verify loaded key (shows prefix only).
Manual Payment Flow:request_payment_token – issue a single-use virtual card token ($1–$100) locked to a merchant and optional signed cart intent; execute_payment – two-step process requiring a purpose check and explicit go decision before filling card details; cancel_payment_token – cancel an unused token and refund balance; request_human_approval – pause for user confirmation on risky actions.
Smart Autopilot & Intelligence:auto_pay_checkout – fully autonomous checkout auto-detecting Web3 (USDC) or fiat; get_merchant_hints – fetch platform-specific checkout playbooks (e.g., Shopify, Etsy); report_checkout_fail – report failures via a 14-class enumeration (e.g., bot_detected, card_declined) to improve self-healing; verify_receipt – cryptographically verify signed receipts, returning order status and funds status independently.
Security & Accountability:
Zero-trust design – card data injected via Playwright only at final step and immediately wiped; single-use tokens with TTL; API key rotation on connection; signed intents and receipts create an auditable trail; human oversight for ambiguous actions.
Enables gasless USDC payments on Base using Coinbase Paymaster to sponsor transaction fees, allowing agents to pay without holding ETH.
Provides platform-specific checkout playbooks and hints for Etsy, enabling automated payment completion on Etsy stores.
Provides platform-specific checkout playbooks and hints for Shopify, enabling automated payment completion on Shopify stores.
Provides platform-specific checkout playbooks and hints for WooCommerce, enabling automated payment completion on WooCommerce stores.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Z-ZERO MCP Pay for the item at this link using USDC"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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-serverWhat 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_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.
✅ 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.
Related MCP server: @true402.dev/mcp-server
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_checkoutdetects a crypto-native checkout (EIP-681), it skips the card flow entirely and settles as a gasless USDC transfer on Base — see above.
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
npx z-zero-mcp-serverAdd 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
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.
Node.js v18+ — nodejs.org
Passport Key — starts with zk_live_, get it from the dashboard above
Tool | Description |
| List all virtual card aliases and balances |
| Check spendable USD balance for a card alias |
| Get your Base deposit address to top up with USDC (stablecoin on Base) |
| Activate a new Passport Key instantly, no restart needed |
| Check if a Passport Key is currently loaded (prefix only) |
Tool | Description |
| Issue a JIT single-use virtual-card token for a specific amount (1hr TTL). Pass |
| Two calls required: first without |
| Cancel an unused token and refund to wallet |
| Pause and request human confirmation before proceeding |
Tool | Description |
| Fully autonomous checkout — auto-detects Web3 or Fiat and completes payment |
| Fetch platform-specific checkout playbook (pre-steps + selectors) from Knowledge Base |
| Report a failed checkout with a structured |
| 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.
Four linked records and controls an agent can use here that it cannot get from a normal virtual card alone.
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.
go or pauseexecute_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_payment({
token,
checkout_url,
actual_amount: 44.00,
recheck: {
page_shows: "2 matte-white mugs, delivered total $44.00",
decision: "go"
}
})Use decision: "pause" when anything differs. The card is not filled and the
token remains active and refundable. On go, the checkout runs; if the merchant
confirms the order, the declaration is sealed into the signed receipt with the
outcome. The platform records what the agent declared; it does not independently
inspect the page or certify that the declaration was true.
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.
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.
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/cardsReturns 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/issueIssue a JIT payment token.
POST /api/tokens/resolveResolve a token to card data (server-side only).
POST /api/tokens/burnBurn a used token.
POST /api/tokens/cancelCancel an unused token (refunds balance).
Copy your Passport Key (starts with zk_live_)
Add it to your config as Z_ZERO_API_KEY
Restart Claude Desktop / Cursor
Double-check you copied the full key (e.g. zk_live_c0g3l)
Make sure there are no extra spaces or line breaks
/api/v1/cardsThis is a legacy path alias — it should now work. If not, use /api/tokens/cards directly.
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.
⚠️ MANDATORY: Read mcp://resources/sop first. Only use on PAYMENT pages where final total is visible. Auto-detects Web3 or Fiat and completes payment. For physical goods (Shopify, Etsy), get_merchant_hints first.
| Name | Required | Description | Default |
|---|---|---|---|
| card_alias | Yes | Card alias to charge for JIT Fiat fallback, e.g. 'Card_01'. | |
| checkout_url | Yes | Full URL of the checkout/payment page to analyze and pay. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full transparency burden. It discloses the auto-detection behavior and preconditions, but does not mention side effects like card charging, failure outcomes, or potential human approval triggers. Given the critical financial nature of the tool, this is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with a front-loaded mandatory warning, making it highly scannable. Every sentence contributes critical information (SOP requirement, usage condition, alternative step) without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key prerequisites, usage constraints, and an alternative for physical goods. It doesn't describe post-payment behavior or response format, but the simple 2-parameter schema and lack of output schema make this less critical. Overall, it is reasonably complete for a high-stakes action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters (checkout_url and card_alias) well-described in the schema itself. The description adds no additional parameter detail, but the schema already provides sufficient semantic meaning, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Auto-detects Web3 or Fiat and completes payment' on payment pages, which is a specific verb and resource. It also includes a conditional ('Only use on PAYMENT pages where final total is visible'), but it doesn't explicitly distinguish itself from the sibling tool 'execute_payment', though the auto-detection detail provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context: 'Only use on PAYMENT pages where final total is visible' and a mandatory prerequisite 'Read mcp://resources/sop first'. It also names an alternative for physical goods ('get_merchant_hints first'), giving clear guidance on when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel unused token and refund instantly. Use when user cancels the purchase or to free up a card slot.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The payment token to cancel | |
| reason | Yes | Reason for cancellation, e.g. 'Price mismatch: checkout shows $20 but token is $15' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full weight. It discloses that the tool cancels a token and refunds instantly, and implies freeing a card slot. However, it omits important behavioral details such as irreversibility, prerequisites (e.g., token must be unused), or failure modes (e.g., token already used).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences, with the primary action front-loaded. Every word earns its place; no filler or redundancy. It efficiently combines purpose and usage guidance in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required params, no output schema), the description covers purpose, usage, and one behavioral side effect (refund and freeing a card slot). It stops short of a 5 by not mentioning reversibility or potential errors, but overall it provides sufficient context for an agent to invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: both token and reason parameters have descriptions. The tool description does not add extra meaning about parameter formats or constraints beyond the schema. It slightly implies the token should be unused, but that is a condition, not a parameter clarification, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource combination: 'Cancel unused token and refund instantly.' This explicitly states the tool's primary action and object, distinguishing it from siblings like request_payment_token (creates tokens) and execute_payment (uses tokens). The name aligns perfectly with the described functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit contexts for use: 'Use when user cancels the purchase or to free up a card slot.' This gives clear situational guidance. However, it does not mention when not to use the tool or suggest alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check spendable USD balance for a card alias. For active token limits, use list_cards instead.
| Name | Required | Description | Default |
|---|---|---|---|
| card_alias | Yes | The alias of the card to check, e.g. 'Card_01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly indicates a read-only balance check via the verb 'Check' and specifies the scope as 'spendable USD balance.' It does not mention error cases or exact output format, but for a simple read operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The core purpose is front-loaded, and the second sentence adds a valuable pointer to an alternative tool. This is efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is complete enough: it states what is checked, on what resource, and directs to an alternative for a different but related use case. No further context is needed for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter card_alias, including an example ('Card_01'). The description reiterates the parameter name but adds no extra meaning beyond what the schema already states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check spendable USD balance') and the resource (a card alias). It differentiates itself from the sibling tool list_cards by specifying that list_cards is for active token limits, making the purpose distinct and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives an alternative tool for a related but different need ('For active token limits, use list_cards instead'), which provides clear when-to-use and when-not-to-use guidance. This is a model example of usage differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a payment with a one-time token: Z-Zero opens a headless browser, injects the card (you NEVER see the PAN), clicks Pay, then watches for a REAL confirmation before reporting success. Returns a status: confirmed (order placed → token burned, receipt_id may hold a real order #), declined (merchant rejected → token kept for refund), unconfirmed (submitted but no confirmation seen → do NOT retry blindly, verify first), not_submitted (no Pay button → supply a submit_selector hint), or no_fields. ALWAYS pass actual_amount so overcharges are blocked and underspend refunded.
| Name | Required | Description | Default |
|---|---|---|---|
| hints | No | Optional hints from get_merchant_hints — selectors and pre-steps to guide Playwright. Use when default selectors fail or for complex multi-step checkouts. | |
| token | Yes | The temporary payment token from request_payment_token | |
| checkout_url | Yes | The full URL of the checkout/payment page | |
| actual_amount | No | STRONGLY RECOMMENDED. The final total shown on the checkout page (incl. shipping + tax). Enables the overcharge block and the underspend refund — omit only if it is genuinely unreadable. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and excels: it reveals that the PAN is never seen, that it waits for real confirmation, defines each status outcome and token lifecycle (burned on confirmed, kept for declined), and describes the overcharge/underspend protection. This is a model of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds useful information about behavior, statuses, or safety thresholds. It front-loads the purpose and uses compact listing of statuses, achieving a high information-to-word ratio.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or annotations, the description compensates by fully enumerating return statuses and their implications for token handling. It also covers both happy path and failure modes (declined, unconfirmed, not_submitted, no_fields) and provides guidance on the actual_amount parameter, making it sufficiently complete for a complex payment execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all 4 parameters with 100% coverage, so the baseline is 3. The description adds value by explaining why actual_amount is strongly recommended (overcharge block, underspend refund) and tying the submit_selector hint to the 'not_submitted' status, which enriches parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Execute a payment') and the resource ('a one-time token'), and adds specific behavioral detail (headless browser, card injection, confirmation watch). However, it doesn't explicitly differentiate from the sibling tool auto_pay_checkout, so it falls short of the highest score for sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong usage context: it instructs to ALWAYS pass actual_amount for overcharge/refund protection, warns against blind retries on 'unconfirmed', and suggests supplying a submit_selector hint when 'not_submitted'. It does not name alternative tools or explicitly state when not to use this tool, so a score of 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your Base deposit address to top up your wallet with USDC (or any supported stablecoin on Base).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses that the address is on Base and supports USDC/stablecoins, but does not specify whether the address changes with each call, any authentication requirements, or that it is a read-only operation. The word 'get' implies non-mutating, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded with the core action ('Get your Base deposit address') and includes necessary context. No extraneous words; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter tool with no output schema, the description provides adequate context: purpose, network, and supported assets. However, it does not mention whether the address is unique per user or per call, or the expected return format, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). Baseline for 0 params is 4; the description adds relevant context about purpose and supported assets, but there are no parameters to explain. The description adds value beyond the schema by specifying the network and asset types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'Base deposit address', clearly stating the tool's purpose. It distinguishes from sibling tools like list_cards or check_balance by focusing on deposit address retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to top up your wallet with USDC (or any supported stablecoin on Base)' provides clear context for when to use this tool. However, it does not explicitly state when not to use it or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get merchant navigation flow for a domain or platform key (e.g. '_platform_etsy'). Returns pre_steps (how to navigate checkout) and platform notes. Call BEFORE starting checkout to understand the multi-step flow.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | The main domain of the checkout page, e.g. 'amazon.com' or 'shopify.com'. Strip 'www.' prefix. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns pre_steps and platform notes, implying a read-only lookup, but it does not explicitly state that it has no side effects, nor does it mention permissions or rate limits. The purpose is clear, but some behavioral traits remain undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three concise, front-loaded sentences. Each sentence adds valuable context: the action and input format, the expected output, and the recommended usage timing. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description adequately covers what the tool does, the input format (including the platform key variant), what it returns, and when to use it. This is sufficient for an agent to invoke it correctly in the broader checkout flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'domain' parameter with examples (100% coverage), but the description adds an alternative accepted format: a platform key like '_platform_etsy'. This information is not present in the schema, meaningfully extending the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get', identifies the resource as 'merchant navigation flow', and highlights the distinction from sibling payment-transaction tools by positioning it as a pre-checkout navigation lookup. It clearly states the tool's scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call BEFORE starting checkout to understand the multi-step flow', providing clear context for when to use the tool. It does not explicitly mention alternative tools, but the sibling tools are clearly different operations, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available virtual card aliases and their balances. No sensitive data is returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It adds one useful behavioral note—'No sensitive data is returned'—which reassures about safety. However, it doesn't explicitly state read-only behavior, authentication requirements, or edge cases like empty lists, so it only partially compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a safety qualifier. Every word earns its place; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description fully explains what it does and what it returns (aliases and balances). The 'No sensitive data' note addresses the main safety concern. There is no missing information for this level of complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter details because none exist, and the baseline for 0 params is 4. No further clarification needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('all available virtual card aliases and their balances'), which unambiguously defines the tool's function. It also distinguishes itself from siblings like check_balance by emphasizing 'all' cards rather than a single balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need to see all virtual card aliases and their balances. It doesn't explicitly name alternatives or exclusions, but the scope ('all available') implicitly differentiates it from check_balance and similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a checkout you could not complete. Pick the failure_class that best matches what you saw — this feeds Z-ZERO's self-healing loop (labeled failures become better merchant hints for the next run). If nothing fits, use 'unknown' and describe what happened in error_message.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The checkout/payment page URL where the purchase failed. | |
| step | No | Where it failed: 'navigate' (page load), 'pre_steps' (shipping/navigation steps), 'fill_form' (card fields), 'submit' (Pay button), 'confirm' (after submitting). | |
| error_message | No | Brief description of what you saw, e.g. 'Card number field is inside a new iframe' or 'Page redirected to CAPTCHA'. NEVER include card numbers. | |
| failure_class | Yes | Fixed failure class: 'card_declined_issuer' (card rejected by bank), 'card_declined_bin_block' (merchant refuses prepaid/virtual cards), 'avs_mismatch' (billing address rejected), '3ds_required' (extra verification/SCA screen appeared), 'bot_detected' (CAPTCHA/Cloudflare/'unusual activity'), 'form_changed' (expected field or button not found), 'price_changed' (total differs from expected), 'out_of_stock', 'shipping_unsupported' (cannot ship to address), 'login_required' (checkout demands an account), 'timeout', 'outcome_unconfirmed' (submitted but no confirmation seen), or 'unknown'. | |
| remediation_tried | No | What you already tried before giving up, e.g. 'retried with submit_selector from hints'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It explains that reports feed Z-ZERO's self-healing loop and influence future merchant hints, which is a meaningful behavioral trait. However, it does not disclose other potential side effects such as whether the report is persisted, reversible, or triggers immediate actions, and it doesn't mention auth/rate limits. The transparency is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every phrase serves a function. It avoids redundancy and directly guides the agent on failure_class selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with full schema descriptions and no output schema, the description covers the key context: purpose, failure_class selection, and the feedback loop. It doesn't explicitly address whether to include optional parameters like remediation_tried, but the schema covers them. The description is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds extra semantics by instructing the agent to pick the best-matching failure_class and to use 'unknown' with an error_message if nothing fits. This decision rule is not present in the schema and clarifies the relationship between failure_class and error_message. It adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Report a checkout you could not complete.' It distinguishes this from sibling tools (which execute payments, list cards, etc.) by focusing on failure reporting, and it explains the downstream purpose via the self-healing loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool: after a checkout cannot be completed. It also gives decision guidance for selecting failure_class, including the fallback to 'unknown' when nothing fits. However, it does not explicitly mention alternatives or when not to use it, though the sibling set makes the unique usage obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause and ask the user for approval before risky actions (price mismatch, large amount, unusual request).
| Name | Required | Description | Default |
|---|---|---|---|
| situation | Yes | Clear description of what the bot found, e.g. 'Checkout shows $20 total (includes $3 tax) but current token is only $15' | |
| current_token | No | Current active token ID if any | |
| alternative_action | No | Alternative option if available | |
| recommended_action | Yes | What the bot recommends doing, e.g. 'Cancel current $15 token and issue a new $20 token' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It clearly states that the tool pauses execution and asks the user for approval, which is the key behavioral trait. However, it does not indicate what happens after the user responds (e.g., return value, whether the action is then executed automatically), leaving a minor gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('Pause and ask') and context ('before risky actions'). It includes relevant examples without unnecessary verbiage. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and full parameter documentation, the description provides adequate context for an agent to understand purpose and usage. However, with no output schema, the description could have briefly mentioned what the tool returns (e.g., user's approval decision), which is a minor omission. Overall, it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have schema descriptions (100% coverage), so the baseline is 3. The description itself adds no additional parameter-specific meaning beyond what the schema already provides. The schema already includes examples for 'situation' and 'recommended_action', so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Pause and ask the user for approval before risky actions' with specific examples (price mismatch, large amount, unusual request). This distinguishes it from sibling tools like auto_pay_checkout and execute_payment, which actually perform actions, whereas this tool interjects a human-in-the-loop checkpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly enumerates when to use the tool: 'before risky actions' and lists example scenarios. While it doesn't name alternatives directly, the context is clear: use this before proceeding with risky operations. The absence of explicit 'when not to use' guidance is a minor gap, but the examples provide sufficient direction for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Request a single-use JIT virtual card ($1–$100) locked to one amount + merchant. ⚠️ Read mcp://resources/sop first. Only call once the FINAL total is visible — for physical goods that is AFTER shipping is submitted (use get_merchant_hints to navigate there). For digital goods with the price already visible, prefer auto_pay_checkout instead. BEFORE requesting: look at the checkout page one more time and compare it against what the user actually asked for — same items, same quantity, same variant, same destination? If anything differs, do NOT request a token; fix the cart or check with the user first. A mismatch you catch here costs nothing; after this point it costs a card. If you pass cart, the server signs your declared intent and binds the card to it — the user gets cryptographic proof of what this card was authorized for.
| Name | Required | Description | Default |
|---|---|---|---|
| cart | No | RECOMMENDED: the items you are buying, as the USER agreed to them. This becomes a signed intent bound to the card — proof of what was authorized. | |
| amount | Yes | Amount in USD to authorize (min: $1, max: $100) | |
| ship_to | No | Shipping destination as a single string (only a hash is stored, never the raw address). | |
| merchant | Yes | Name or URL of the merchant/service being purchased | |
| card_alias | Yes | Which card to charge, e.g. 'Card_01' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the card is single-use, JIT, locked to one amount and merchant, that passing `cart` creates a signed intent with cryptographic proof, and that a mismatch caught after this point 'costs a card.' It also mentions the prerequisite of reading the SOP, providing rich behavioral context beyond a simple 'request' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than the calibration examples, but every sentence earns its place: it front-loads the core purpose, then presents critical warnings, timing rules, an alternative, and a safety checklist. The structure is logical and scannable with a clear warning symbol. Slightly verbose but appropriately sized for the tool's high-stakes nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of an output schema, the description is nearly complete. It covers prerequisites (SOP), timing, alternatives, safety checks, and the binding behavior. The only gap is that it does not describe the return value (e.g., the shape of the token response), which would be useful since no output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics to the `cart` parameter, explaining it is 'RECOMMENDED' and that it becomes a signed intent bound to the card, which is more than the schema's dry description. However, other parameters like card_alias and merchant receive no extra semantic enrichment beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, unambiguous verb+resource statement: 'Request a single-use JIT virtual card ($1–$100) locked to one amount + merchant.' This precisely defines the tool's function and explicitly distinguishes it from the sibling tool auto_pay_checkout by stating when to prefer that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Only call once the FINAL total is visible' with distinct rules for physical vs. digital goods, and names auto_pay_checkout as the alternative for digital goods. It also mandates reading a SOP resource and includes a pre-request verification checklist, offering clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Activate a new Passport Key instantly, no restart needed. Only call when user explicitly provides a key.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | The new Passport Key to activate. Must start with 'zk_live_' or 'zk_test_'. Get from: https://z-zero.xyz/dashboard/agents |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that activation is immediate and requires no restart, and that it should only be invoked with explicit user-provided keys. However, it does not disclose potential side effects such as overwriting the existing key or whether the operation is reversible, which is important for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action and key qualifier. Every word earns its place; no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (single parameter, no output schema, no nested objects), the description covers the essential aspects: what it does, when to call, and a behavioral benefit. It lacks explicit mention of replacing the old key, but the tool name and schema imply the setter semantics. Overall, it is sufficiently complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter, with details on prefix format and where to obtain keys. The tool description adds 'new' and the usage constraint, but this is marginal beyond the schema. Baseline of 3 applies because the schema already provides comprehensive parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Activate' and the resource 'a new Passport Key', which is immediately clear and distinguishes from sibling tools like show_api_key_status that only checks status. It also adds meaningful qualifiers 'instantly, no restart needed' that define the tool's specific effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear when-to-use gate: 'Only call when user explicitly provides a key.' This effectively tells the agent not to guess or infer a key. However, it does not explicitly mention alternatives like show_api_key_status for checking current status, so it lacks the explicit alternative naming seen in top-tier examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if Passport Key is configured. Shows prefix only, for debugging.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully reveals that only the prefix is shown, which is a notable behavioral limitation. However, it does not disclose what the tool returns (e.g., a boolean, a status message) or any side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that are front-loaded with the core purpose and then add the behavioral caveat. Every word earns its place, with no verbosity or redundancy. It is a model of concise, effective writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and empty schema, the description covers the main action but omits the return format, which is critical because there is no output schema to provide that information. It does not explain what the status output looks like, making the description less complete than it could be for a debugging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so the description does not need to elaborate on parameter semantics. The baseline for zero parameters is 4, and the description appropriately says nothing about parameters, which is correct for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking whether the Passport Key is configured. The verb 'check' and the resource 'Passport Key' are specific, and the mention of showing only the prefix distinguishes it from tools like set_api_key that manage the key. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for debugging by stating 'for debugging,' but it does not explicitly state when to use this tool versus alternatives like set_api_key or get_merchant_hints. No exclusions or alternative references are provided, so the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check where an order ENDED UP, and prove it. Returns TWO separate axes: order_status — 'completed' (bought, issuer not reported yet) · 'settled' (issuer confirmed) · 'reversed' (auth voided before clearing — the order does NOT stand) · 'partially_refunded' / 'refunded' (merchant returned money AFTER settlement — the order still happened) — and funds_status — 'no_payout_due' · 'payout_pending' (money owed back but not yet confirmed on-chain) · 'returned' (confirmed on-chain). Read BOTH before speaking: 'reversed' or 'refunded' with funds 'payout_pending' means the buyer has NOT got the money back yet — never say they have. If you told the user a purchase was done and a later check returns 'reversed', tell them unprompted.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt_id | Yes | The receipt_id returned by execute_payment / auto_pay_checkout (signed_receipt.receipt_id). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It goes above and beyond by detailing all possible status values, warning that 'reversed' or 'refunded' with 'payout_pending' means the buyer has NOT got the money back, and instructing the agent to proactively inform the user of status changes. No contradictions with annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured, using dashes and explicit value lists to organize the two axes. It front-loads the purpose, and every sentence/section adds unique value—status definitions, funds status logic, and an important caveat. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema, the description fully compensates by explaining the return structure (two axes), enumerating all possible values with meanings, and providing decision rules. It is complete for an agent to correctly interpret the result and act on it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the single parameter receipt_id, explaining it as the receipt_id from execute_payment/auto_pay_checkout. The description does not add parameter-level detail, which is fine given the schema's completeness, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check where an order ENDED UP, and prove it.' It uses a specific verb (verify/check) and resource (receipt/order status), and distinguishes itself from sibling tools like execute_payment or auto_pay_checkout by focusing on post-purchase verification. The two-axis breakdown (order_status and funds_status) further clarifies exactly what is checked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (after a purchase, to verify status) and even instructs on proactive follow-up if a later check shows 'reversed'. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.7.0auto_pay_checkoutcancel_payment_tokencheck_balanceexecute_paymentget_deposit_addressesget_merchant_hintslist_cardsreport_checkout_failrequest_human_approvalrequest_payment_tokenset_api_keyshow_api_key_statusverify_receiptSeveral tools overlap in the payment flow (auto_pay_checkout, request_payment_token, execute_payment) and balance retrieval (list_cards vs check_balance), though detailed descriptions provide usage guidance. The boundaries are not always immediately clear, but the added context reduces misselection risk.
All tool names follow a consistent verb_noun snake_case pattern (e.g., list_cards, request_payment_token). There is no mixing of styles or unexpected abbreviations.
13 tools is well within the typical 3-15 range and each tool serves a clear function in the payment lifecycle. The count feels appropriate for the server's scope.
The tool surface covers the full workflow from deposit and card creation to payment execution and receipt verification. Minor gaps like a transaction history or explicit refund initiation exist, but agents can work around them.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Payment infrastructure for AI agents: spending rules, approval flows, single-use virtual cards.
Agent-commerce MCP server for x402/USDC payments and affiliate splits on Base.
Agent Commerce Protocol MCP — bridges Stripe ACP + Google AP2 + Coinbase x402 for agent payments
15 paid AI agent primitives via x402 (USDC on Base). Pay-per-call MCP server.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dempty-glitch/Z-Zero-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
