List all 35 XRPL actions that build_xrpl_transaction can produce. For each you get: id, plain-English label, category, safety tier, and every parameter (name, type, required, example). Call this FIRST so you pass the right product_id and params in one shot instead of guessing and getting a missing-params error. No parameters. Free, no signup.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains what the tool returns, that it has no parameters, and that it is free/no-signup, which implies a risk-free read operation. It could add a bit more about response format or mutability, but the lack of parameters and the list-only framing make the behavior sufficiently clear.
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?
Three short sentences, each earning its place: what the tool returns, when to call it, and the no-parameter/no-cost caveat. It is front-loaded with the core purpose and avoids repetition of the input schema.
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?
Despite having no output schema, the description explains the exact output contents (id, label, category, safety tier, parameters with details). It also connects itself to the sibling workflow by referencing product_id and params, making it complete for an agent deciding whether to call 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 tool has zero parameters and the schema already covers this completely. The description reinforces 'No parameters' and explains what information the agent will receive instead, which is appropriate for a no-parameter catalog tool. No additional parameter documentation is 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?
States a specific verb ('List') and a specific resource ('all 35 XRPL actions that build_xrpl_transaction can produce'), and clearly distinguishes itself from the build_xrpl_transaction sibling by being the upfront catalog. The output fields are enumerated, so an agent immediately knows what this tool is for.
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?
Explicitly instructs 'Call this FIRST' and explains the consequence of not doing so: guessing and getting a missing-params error. This directly guides the agent to use this tool before build_xrpl_transaction, giving clear when-to-use context and the rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The tools generally split cleanly by resource: scores, credentials, MPTs, transactions, and community fund. The three MPT-related tools and the score-lookup vs score-credential pair could briefly overlap in purpose, but their descriptions are detailed enough to resolve the ambiguity.
All tool names follow a consistent snake_case verb_noun pattern with clear verbs such as check, get, list, search, build, submit, verify, donate, and issue. There is no mixing of naming styles or vague generic verbs.
Thirteen tools is well-scoped for a server covering XRPL scores, credentials, MPTs, transaction building, and community fund actions. The 35 supported transaction types are sensibly collapsed behind list and build tools rather than exploding into dozens of endpoints.
Core workflows are covered: score lookup, credential verification, MPT risk and search, transaction building, and community fund participation. Minor gaps exist, such as no standalone grant-status lookup or explicit score-credential verification endpoint, but these are workable around.