XRPLHub — XRPLScore & XRPL actions

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

With no annotations, the description carries the full behavioral burden, and it addresses the most important risk: 'this never signs for anyone' and the wallet owner signs in their own wallet. It also reveals the return includes a safety tier. It does not explain what the safety tier means or what happens on invalid input, leaving some behavioral gaps.

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 front-loaded with the purpose and output, then covers the critical safety behavior, the prerequisite call, and the parameter shape without wasted words. It is dense but every clause earns its place for a tool of this complexity.

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?

The description compensates for the lack of an output schema by explaining the return type (exact txjson plus safety tier) and directs the user to list_xrpl_services for per-service details. It does not define the safety tier or show a txjson example, but for a builder tool the prerequisite and parameter guidance are sufficient for an agent 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%, including detailed per-service required parameters, so the schema already does the heavy lifting. The description restates the three parameters and gives a few product_id examples, but it adds no meaning beyond the schema, which places it at the baseline.

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 clearly states a specific action: it returns a ready-to-sign transaction JSON for any of 35 XRPL actions, with a concrete output (txjson plus safety tier). It is less explicit about how this relates to the sibling issue_score_credential, since the enum includes credentialissue, so it doesn't fully distinguish itself from all siblings.

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?

The description gives a clear context for use—building a signable transaction without XRPL coding—and an explicit prerequisite: call list_xrpl_services first for the full catalogue and parameter examples. It does not state when not to use this tool or how to route around overlapping tools like issue_score_credential, so it falls short of a 5.

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

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

With no annotations, the description carries the full disclosure burden and does well: it states live mainnet behavior, OR eligibility semantics, accepted/expired credential rules, and 'Free, no signup' for auth. It does not mention return format or error behavior, which prevents a 5.

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 informative, with useful facts front-loaded: mainnet live, OR logic, params, and no signup. The rhetorical phrase 'the question every domain operator...' adds flavor but not function, slightly reducing conciseness.

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 simple read-only eligibility check with two required params and no output schema, the description covers the core semantics well: what is checked, the OR condition, live mainnet behavior, and auth requirements. It omits explicit return value/error details, which would make it more complete.

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 coverage is 100%, so the baseline is 3. The description mostly restates the schema's parameter info, but it adds meaningful interaction semantics: 'Eligibility is OR: any ONE accepted, unexpired credential matching the domain's AcceptedCredentials is enough', clarifying how wallet_address and domain_id relate.

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 states a specific verb and resource: 'Check whether an XRPL account holds a credential that satisfies a PermissionedDomain (XLS-80d)'. This clearly differentiates the tool from siblings like check_xrpl_score, check_mpt_risk, and get_account_credentials by focusing on PermissionedDomain eligibility.

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?

The description gives clear context: it is the check 'before a real transaction' and operates 'against a validated mainnet ledger'. It does not explicitly name alternative tools or state when not to use it, so it stops short of a 5, but the intended use case is clear.

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

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

There are no annotations, so the description carries the full behavioral burden. It discloses key operational traits: the tool is free, requires no signup, every response states its source, and unmatched issuances return 'unknown' rather than 'does not exist'. The phrase 'Get the risk view' also conveys a read-only intent.

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 longer than the minimum but each sentence earns its place: risk semantics, pricing, an explicit alternative, edge-case behavior, and the required parameter. The 'Params:' sentence is somewhat redundant with the schema, but the description remains front-loaded with purpose and well organized.

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?

Though there is no output schema, the description conveys the essential response content: issuer powers, XRPLScore, source attribution, and the not-found behavior. With one fully documented required parameter and no annotations, the description gives an agent enough context to select and invoke the tool 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%, so the input schema already fully documents issuance_id as a required 48-hex MPTokenIssuanceID. The description repeats this information but adds no additional parameter-level meaning beyond what the schema provides, warranting the baseline score.

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 uses a specific verb ('Get the risk view') with a precise resource ('one XLS-33 Multi-Purpose Token issuance') and enumerates concrete risk dimensions (clawback, freeze, require-auth, transferability) plus the issuer's XRPLScore. This clearly distinguishes it from siblings like check_xrpl_score, check_domain_eligibility, and get_issuer_mpts.

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?

It explicitly frames when to use this tool ('before touching it') and directly names an alternative for a fuller picture, including the cost and endpoint. This gives an agent actionable routing guidance without ambiguity.

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

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

There are no annotations, so the description carries the full transparency burden. It discloses that this is a read-only, public-ledger operation ('100% public ledger data'), that no API key or signup is required, and exactly what the caller receives. It stops short of covering failure modes or data freshness, but the essential behavioral profile is 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?

The description is tightly organized: action and use case first, then the return payload, then the parameter, then access requirements. Every sentence adds useful information without fluff or repetition beyond a compact params reminder.

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, this description is unusually complete. It explains what the score means, the range, the signals used, the returned artifacts, the required address format, and the access model, so an agent has enough context 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 coverage is 100% for the single required parameter, and the schema already specifies that wallet_address starts with 'r' and is 25–35 characters. The description repeats these constraints rather than adding new semantic detail, so it meets the baseline but does not elevate it.

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 verb and resource: 'Get a 300–850 creditworthiness score for any XRP Ledger wallet.' It also enumerates the exact output components (score, letter grade, percentile, per-signal breakdown, tips), which makes the tool's function unmistakable and separates it from sibling tools like check_mpt_risk or issue_score_credential.

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?

The description gives clear usage context: 'before you pay, lend to, trade with, or onboard it.' It does not explicitly state when to avoid this tool or name an alternative for different wallet checks, but the intended decision-making context is well conveyed.

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

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

With no annotations, the description carries the behavioral burden and does a solid job: it states the return values (treasury address and txjson when donor_wallet is supplied), the on-chain transparency of donations, zero overhead, and no signup. 'Ready-to-sign' suggests the transaction is not yet signed/broadcast, which is useful behavioral context, though it is not spelled out that signing/submission is a separate step.

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 front-loaded with the core purpose and includes only a few contextual clauses. The inline parameter summary is redundant given the 100% schema coverage, but it is compact and does not seriously bloat the text.

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?

Even without an output schema, the description explains what the caller receives and why the fund is trustworthy. It gives enough context for an agent to supply amount, choose currency, and optionally pass donor_wallet/message. A minor gap is the lack of an explicit statement about the downstream signing/broadcast workflow for the returned txjson.

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?

All four parameters have rich descriptions in the schema, so the baseline is 3. The description's inline 'Params' list mostly restates the schema without adding new semantic information, and the schema already covers the amount minimum, currency default, and optional fields.

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 action and object: 'Donate XRP or RLUSD to the XRPLHub Community Grant Treasury.' This unambiguously identifies the tool's purpose and separates it from nearby tools like submit_grant_application, which is for grant applicants rather than donors.

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?

The intended use case is clear: use this tool when donating XRP/RLUSD to the community grant treasury. The 'No signup' note and the promise of a ready-to-sign Payment txjson also imply a low-friction donation path distinct from a generic transaction builder, though no sibling is explicitly named as an alternative.

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

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

With no annotations provided, the description carries the full burden, and it delivers rich behavioral detail: it is live against a validated mainnet ledger, never stale, bounded at ~20s for the default walk, with a coverage field of complete/partial, and a direct-lookup mode that is always fast and complete. It also discloses that the result can be partial for large exchange-scale accounts, which is critical for correct use.

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?

Every sentence earns its place: purpose, use case, default behavior, alternative mode, parameter summary, and access requirements. The information is front-loaded and dense without being wordy, and the dash-separated parameter list makes it scannable.

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?

Even without an output schema, the description tells the agent what the response will contain (issuer, type, accepted, expired, expiry date) and the completeness semantics. It covers performance characteristics, the two invocation modes, parameter constraints, and access prerequisites. An agent has enough to decide when to call it and how 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%, and the schema already explains the direct-ledger-lookup behavior for issuer and the conditional requirement for credential_type. The description mostly restates this, adding only minor conveniences like the 'r...' format and 'name or hex'. It does not meaningfully extend the parameter semantics beyond what the schema already provides.

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 verb and resource: 'Get every XLS-70 credential an XRPL account holds', and lists the exact attributes returned (issuer, type, acceptance, expiry, expiry date). This clearly distinguishes it from sibling tools like get_issuer_credentials or search_mpts by targeting credentials held by an account rather than issued or listed elsewhere.

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?

The description explicitly says when to use it: 'Use this before trusting a counterparty who claims to hold a credential.' It also provides clear routing between the default owner-directory walk and the faster direct lookup when an issuer is passed. It does not explicitly name alternative sibling tools as exclusions, so it falls just short of a 5.

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

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

With no annotations, the description carries the burden and handles it well: it discloses the census/cached nature, the periodic rebuild, the coverage field, and the risk of mistaking a partial answer for final, plus free/no-signup access. This goes beyond a simple read hint.

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 compact chunks—purpose, provenance/coverage caveat, and param/access note—are front-loaded with no filler. Every sentence adds decision-relevant information.

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 read tool with no output schema and no annotations, the description covers what data is returned, that it may be partial, and what access is needed. It does not spell out the exact response shape or update cadence, but these are minor for invocation.

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 schema already fully documents issuer_address with a description, so the description adds little beyond restating it as required and noting the r-prefix. Baseline 3 is appropriate when schema coverage is complete.

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 uses a specific verb ('Get'), names the resource ('everything an issuer account has issued'), and enumerates the returned dimensions (credential type, distinct subject count, acceptance rate), making it clear what the tool does and separating it from account-level or MPT-focused siblings.

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?

The issuer-account wording and the list of aggregate metrics provide a clear context for when to call it. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

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

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.

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

With no annotations provided, the description carries full behavioral weight and does so thoroughly: it discloses the two-call stateful flow, the 1 XRP/RLUSD payment requirement, 90-day validity, the need to sign in Xaman, and the returned artifacts. No annotation contradiction exists.

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 compact sentences lead with the value proposition, then workflow, then parameters. Every sentence adds necessary context, including cost, validity, and the no-signup note, with no filler.

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?

The tool has no output schema, so the description appropriately explains what each call returns. It covers the full issuance lifecycle, payment details, validity period, and parameter roles, making it complete for an agent to invoke 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 coverage is 100%, so baseline is 3. The description largely restates schema information for wallet_address, currency, and uuid, adding only minor workflow framing via '2nd call only' and the default currency. It does not substantially enrich parameter meaning beyond the schema.

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 and resource: 'Get a signed, tamper-evident certificate of a wallet's XRPLScore.' It also distinguishes itself from the free score by explaining that this version is provable to a third party, making its purpose and differentiator clear.

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?

Provides explicit two-call usage instructions: first call gets a payment request, second call with wallet_address and uuid returns certId and verifyUrl. It implies when this should be preferred over the free score, though it does not explicitly name an alternative sibling tool.

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

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.

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

With no annotations provided, the description carries the full behavioral burden. It discloses that results are served from an index (not live), that coverage may be 'complete' or 'partial,' and that 'partial' should be treated as a floor. It also notes the response includes lastCompletedPassAt and source. It does not detail rate limits or error behavior, but the most important non-obvious behavioral trait (partial coverage) is explicitly surfaced.

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, information-dense, and well-ordered: what it searches, what it returns, how to interpret the index coverage, and the parameter. Every sentence earns its place, and the critical caveat about 'partial' coverage is front-loaded in the middle. No filler.

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 single-parameter search tool with no output schema, the description covers the search target, return fields, coverage semantics, and cost/auth requirements ('Free, no signup'). It could mention source values (e.g., what 'source' refers to) or example queries, but for an agent to invoke it correctly with q, the description is nearly sufficient.

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%, so the baseline is 3. The description reinforces the meaning of 'q' by listing the accepted forms (issuer address, MPTokenIssuanceID or hex prefix, token name/ticker) but does not add formatting details, case sensitivity, or examples. The schema already documents the parameter adequately; the description adds modest enrichment.

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 names a specific verb ('Search'), a specific resource ('XRPL Multi-Purpose Token (XLS-33) registry index'), and the exact search dimensions (issuer address, MPTokenIssuanceID/hex prefix, token name/ticker). It also lists return fields, making it unmistakable what the tool does and how it differs from sibling tools like get_issuer_mpts (which fetches MPTs for a specific issuer) and verify_mpt_registry (which verifies registry membership).

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?

The description clearly states when to use this tool: when searching the registry by issuer, ID, or ticker. It also signals the index-backed nature and coverage semantics ('partial' as a floor), which helps an agent decide if results are sufficient. It does not explicitly name sibling alternatives to avoid, but the purpose clarity and context make the appropriate usage reasonably inferable.

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

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

With no annotations provided, the description carries the full burden. It discloses the key behaviors: it returns a grant id and status, involves AI triage and human approval, pays approved RLUSD directly to the wallet, and has no middleman. It does not cover failure modes or idempotency, but for a submission tool the core behavioral contract is clearly exposed.

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 dense and well-structured: it leads with purpose, then the process and return value, then a compact parameter summary. Every section contributes useful information, though the parameter list partly duplicates the schema. Minor redundancy keeps it from a 5.

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?

Given there is no output schema, the description usefully names the return values (grant id and status) and explains the approval and payout flow. It covers amount limits, categories, wallet format, and description requirements. The only notable omission is the optional currency parameter, which the schema covers, so the description is nearly complete.

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%, so the schema already documents all five parameters including constraints and guidance. The description compacts the same parameter information into a quick reference but does not add meaning beyond the schema, apart from emphasizing the r... wallet format and the description length. Baseline 3 is appropriate.

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 verb and resource: 'Apply for a community micro-grant,' and immediately bounds it with amount range, eligible categories, and payout mechanism. This clearly distinguishes it from sibling tools like donate_to_community_fund (the opposite direction) and build_xrpl_transaction (general transaction building).

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?

The description makes the intended use obvious: apply when seeking a 1–100 RLUSD micro-grant for listed living expenses. It also conveys the workflow (AI triage, human approval, wallet payout) and removes a potential barrier with 'No signup.' It does not explicitly name alternatives or exclusion cases, but the context is strong enough.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly describes an on-ledger read operation, lists the returned fields, notes the reproducibility workflow, and states there are no parameters, free access, and no signup. This is strong transparency, though it does not discuss potential failure modes or rate limits.

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 dense but well-organized, front-loading the core purpose, then the return payload, then the verification workflow, and finally access requirements. Every sentence adds value and no content is redundant.

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 no-parameter, read-only verification tool with no output schema, the description provides a complete picture: what it does, what it returns, how it can be reproduced from external data, and what it enables. An agent can confidently select and invoke this tool without further clarification.

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 reflects that. The description explicitly confirms 'No params,' leaving no ambiguity for the agent about required or optional inputs.

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 verb and resource: 'Get the latest on-ledger anchor of the MPT registry.' It further details that the anchor is a Merkle root committed in a Memo, and the purpose is to confirm the registry has not been altered, clearly distinguishing this verification tool from MPT search/risk siblings.

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?

The description states the tool is used to retrieve the registry anchor and verify registry integrity by reproducing the root from published data. It gives clear context for when to call it, though it does not explicitly name alternatives or state when not to use it.

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