Skip to main content
Glama

SCRIPTMASTERLABS — 402Proof

verify_payment

Submit tx_hash after paying an invoice. Supports XRPL, Xahau, Base (0x… hash), and Solana. Returns a signed JWT access_token (1-hour TTL). For a Xahau invoice with fee_required=true, also submit fee_tx_hash (the 0.01 XAH facilitator-fee payment) — settlement requires both payments. Free.

Input Schema

NameRequiredDescriptionDefault
tx_hashYesXRPL/Xahau: 64-char hex; Base: 0x-prefixed hex; Solana: base58 signature
invoice_idYes
fee_tx_hashNoXahau only, when the invoice has fee_required=true: tx hash of the 0.01 XAH facilitator-fee payment to fee_pay_to carrying fee_memo_hex
agent_domainNo
agent_walletYes
recovery_secretYesPrivate high-entropy secret returned only with the original invoice; required to recover a previously settled token after lost response/restart

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose valuable traits a schema cannot: returns a signed JWT access_token with a 1-hour TTL, requires both on-chain payments for Xahau fee_required settlement, and is free. It says nothing about failure modes, idempotency, or whether the tx must be confirmed on-chain before submission, which are the behaviors that matter most for a settlement-verification call.

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?

Four short clauses, each with distinct payload: the action, the chain formats, the JWT return with TTL, the Xahau dual-payment caveat, and the cost. The main instruction is front-loaded and nothing is redundant.

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?

For a 6-parameter tool with no annotations and no output schema, the description does cover the return value (signed JWT, 1-hour TTL) and the tricky Xahau case. But the roles of agent_wallet and agent_domain, and the relationship the submitted tx_hash must have to the invoice, remain unexplained, leaving real gaps for a mutation-style settlement call.

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 50%: tx_hash, fee_tx_hash, and recovery_secret are already documented in the schema, and the description mostly restates those (format per chain, fee_required condition). The undocumented parameters invoice_id, agent_wallet, and agent_domain get no semantic explanation in the description, so the coverage gap is not compensated.

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?

States a specific verb and resource (submit tx_hash to verify payment for an invoice) plus the supported chains and the return artifact, so the action is unambiguous. It does not explicitly differentiate itself from siblings like get_invoice or get_compliance_receipt, leaving the agent to infer the invoice-then-verify sequence.

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?

"Submit tx_hash after paying an invoice" gives a clear precondition, and the Xahau branch ("with fee_required=true, also submit fee_tx_hash") is an explicit conditional instruction. There is no guidance on failure/retry paths, whether it can be re-called for an already-settled invoice, or which sibling to use instead for read-only invoice lookups.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources