Skip to main content
Glama

Zambo

by io.github.zambodotdev
OverviewDiscussionsAdmin

day_pass_activate

Agent-native Day Pass entry. Call with no arguments to create a $1.49 USDC payment intent on Base. After payment, call again with payment_intent and tx_hash to verify and activate 24-hour access. Never activates without a verified transfer. When to use: call day_pass_activate when the user's request matches this capability. When not to use: do not call it for unrelated work, missing required inputs, or when a safer read-only route is more appropriate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tx_hashNoConfirmed Base USDC transaction hash.
payment_intentNoServer-issued payment intent from the first call.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
activatedNo
expires_atNo
x711_creditsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • removedInput schema / properties / email
      Removed value: -{
-  "description": "Your email address — used to link the 24h pass to your account.",
-  "type": "string"
-}
    • addedInput schema / properties / payment_intent
      Added value: +{
+  "description": "Server-issued payment intent from the first call.",
+  "type": "string"
+}
    • changedInput schema / properties / tx_hash / description
      Previous value: -"Transaction hash after sending payment. USDC on Base: get from your wallet or basescan.org. $ZAMBO on Solana: get from your wallet or solscan.io."New value: +"Confirmed Base USDC transaction hash."
    • removedInput schema / required
      Removed value: -[
-  "email",
-  "tx_hash"
-]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare this is a write operation (readOnlyHint=false) that isn't idempotent and isn't destructive. The description adds meaningful behavior beyond that: the two-call protocol and the hard guarantee that activation never occurs without a verified transfer. Failure/payment-error handling is not covered, but the key behavioral constraints are.

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 core capability and the two-step flow are front-loaded and efficient. The trailing 'When to use / When not to use' paragraphs are generic filler that restate the obvious, preventing a perfect score.

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?

With an output schema present, return values need not be described. The description covers the payment-to-activation lifecycle and the verification gate, leaving only minor gaps such as what happens on payment failure.

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 would be 3. The description goes further by explaining the role each parameter plays in the flow: payment_intent is the server-issued token from the first call, and tx_hash is the confirmed Base USDC transfer used to activate access.

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 states a specific verb and resource with concrete detail: create a $1.49 USDC payment intent on Base, then verify a tx_hash to activate 24-hour access. The two-phase nature of the tool is unambiguous, and no sibling tool (capability_search, live_price, ghost_audit_*, etc.) overlaps with this capability.

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 gives real sequencing guidance: call with no arguments first to create the payment intent, then call again with payment_intent and tx_hash. The generic 'when to use / when not to use' boilerplate adds little, but the explicit two-step invocation flow is genuine guidance an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Zambo toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources