Everything one issuer has put out as Multi-Purpose Tokens (XLS-33), from the registry index, plus the issuer's own XRPLScore. Each issuance lists the issuer's powers over a holder. Response carries coverage ('complete-per-known-issuer'/'partial'). Params: issuer_address (r..., required). Free, no signup.
| Name | Required | Description | Default |
|---|---|---|---|
| issuer_address | Yes | XRPL issuer address (starts with r) |
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 provided, the description carries the behavioral disclosure burden. It does well by revealing that the response includes a coverage status ('complete-per-known-issuer'/'partial'), explaining that each issuance lists the issuer's powers over a holder, and noting it is free and requires no signup. It does not explain what leads to 'partial' coverage or data freshness, but the disclosures are substantive.
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?
The description is compact and front-loaded with the core purpose. Every sentence contributes useful information: scope, source, output composition, coverage, parameter hint, and access conditions. It is slightly dense but not wasteful, earning a strong score.
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?
For a one-parameter tool with no output schema, the description covers the main return contents (MPTs, XRPLScore) and even the coverage nuance. It omits error behavior and exact formatting of the score, but the tool is relatively simple and the description gives enough to invoke it correctly.
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?
Schema description coverage is 100% for issuer_address, so the baseline is 3. The description adds only a duplicate note (r..., required) that mirrors the schema. It does not add meaningful parameter behavior beyond what the schema already states.
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?
The description opens with a specific, well-scoped statement: 'Everything one issuer has put out as Multi-Purpose Tokens (XLS-33), from the registry index, plus the issuer's own XRPLScore.' This clearly identifies the resource (issuer MPTs), the operation (get all), and the unique addition (XRPLScore), effectively distinguishing it from siblings like search_mpts or verify_mpt_registry.
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?
Usage is implied rather than explicit. The description implies 'use when you need all MPTs for a specific issuer and their XRPLScore,' but it never states when not to use it or names alternatives such as search_mpts for cross-issuer queries. There is clear context but no exclusions or explicit routing guidance.
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.