Skip to main content
Glama

XRPLHub — XRPLScore & XRPL actions

preview_xrpl_transaction

FREE. Describe one XRPL transaction before you buy it: what it does, what is irreversible, the price, and every field it needs. Returns NO signable txjson — enough to decide, not enough to sign. Then call build_xrpl_transaction to buy it. Params: product_id (required, from list_xrpl_services), params (optional object; tailors the multisig warning).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNoOptional per-service parameters; only used to tailor the irreversibility wording (e.g. signers, quorum).
product_idYesWhich XRPL action to describe. Call list_xrpl_services for the catalogue.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the disclosure burden. It states the tool is FREE, that it returns no signable txjson, and that the optional params only tailor the irreversibility wording — a real behavioral quirk. It stops short of explicitly stating 'read-only/no side effects,' but 'describe' plus 'not enough to sign' strongly signals safety.

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?

Three front-loaded sentences cover purpose, output constraint, and next step. The final Params line is a compact summary but slightly duplicates schema documentation; otherwise there is no 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?

For a preview tool with no output schema, the description tells the agent what the response contains (description, irreversibility, price, required fields), what it explicitly lacks (signable txjson), and the handoff to build_xrpl_transaction. Nothing essential is missing for correct 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?

Schema description coverage is 100%: both product_id and params already have their meanings documented. The description's Params line essentially repeats the schema ('tailors the multisig warning'), adding no new parameter-level information, so the baseline 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 states a specific verb and resource: 'Describe one XRPL transaction before you buy it' and enumerates the output content ('what it does, what is irreversible, the price, and every field it needs'). It also distinguishes itself from sibling build_xrpl_transaction by explicitly noting it returns 'NO signable txjson'.

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?

Explicitly names the alternative tool and the sequence: 'Then call build_xrpl_transaction to buy it.' It also tells the agent where product_id comes from ('from list_xrpl_services'), giving clear when-to-use and next-step guidance.

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.