Z-ZERO MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.7.0
Disambiguation3/5
Several 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.2/5 across 13 of 13 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 50 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Z-Zero-mcp MCP server](https://glama.ai/mcp/servers/Dempty-glitch/Z-Zero-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Dempty-glitch/Z-Zero-mcp)

Score Badge

Copy to your README.md:

[![Z-Zero-mcp MCP server](https://glama.ai/mcp/servers/Dempty-glitch/Z-Zero-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Dempty-glitch/Z-Zero-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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