XRPLHub — XRPLScore, MPT issuer risk & payment pre-checks

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?

With no annotations, the description carries the full burden and does well: it discloses cost ('Free'), no signup, that every response states its source, and the failure semantic that it returns 'unknown' rather than 'does not exist'. It omits rate limits and whether reads hit the live ledger, so it stops short of exhaustive.

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?

Front-loaded with the core value (risk view and the fields it exposes), followed by cost, the paid alternative, and failure semantics. Dense but nearly every clause earns its place; the pricing detail on the alternative endpoint is the only mildly expendable element.

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?

No output schema exists, so the description must describe returns — and it does, listing the concrete risk fields and the 'unknown' fallback. It leaves the exact response shape and any rate/access limits unspecified, but for a free read-only risk lookup it is largely 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% and the single parameter's format (48-hex MPTokenIssuanceID) is already documented in the schema. The description repeats the same '48-hex MPTokenIssuanceID, required' fact, adding no meaning beyond the structured field, so the baseline 3 applies.

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+resource ('Get the risk view of one XLS-33 Multi-Purpose Token issuance') and enumerates exactly what it returns: clawback, freeze, require-auth, transferability, and issuer XRPLScore. An agent can distinguish this from search_mpts, verify_mpt_registry, or get_issuer_mpts without opening any schema.

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?

Frames the when ('before touching it') and names an explicit alternative: the paid x402 endpoint at GET /api/x402/usdc/mpt/{id} for the full issuer picture. The routing is clear, though it's presented as a paid upgrade path rather than a when-not-to-use-this condition, and no other sibling is compared.

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 full behavioral disclosure responsibility. It explicitly states the return format (overall 'ok' | 'warn' | 'down' plus per-component list), notes that the tool is free and requires no signup, and implies readiness checks without side effects. It does not mention potential rate limits or how to handle a 'down' response, but covers the essential behavior well.

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: the first sentence states the trigger condition and scope, followed by the return format, then usage guidance and cost/friction notes. Every sentence earns its place with no redundancy or 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 zero-parameter tool with no output schema, the description is remarkably complete. It explains what is checked, what the output looks like, when to poll, and that no signup or cost is involved. An agent has enough context to invoke the tool and interpret the result 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?

The tool has zero parameters, and the schema coverage is 100% (empty object). Per the rubric, a baseline of 4 applies, and the description reinforces this with 'No params.' No additional parameter semantics are 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?

The description clearly states the tool's purpose with a specific verb ('Check'), a defined resource ('XRPLHub money path'), and a precise context ('BEFORE you pay'). It enumerates the exact components checked, distinguishing it from sibling tools like check_mpt_risk or check_domain_eligibility, which target entirely different resources.

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: use it before paying and poll it if a prior paid call failed. This tells an agent exactly when to invoke the tool, though it does not explicitly name alternatives or exclusion conditions, leaving room for 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 burden and does so: it discloses the exact cost ($0.02 USDC on Base or RLUSD on XRPL), the endpoint, and the critical behavioral quirk that this tool returns the payment resource to call rather than performing the check. That non-execution caveat is exactly the kind of trait an agent would otherwise get wrong.

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?

Front-loads the core purpose in the first sentence and keeps the payment/non-execution caveat prominent. The output-format sentence and the free-page pointer each earn their place, though the enumeration of permission types is denser than strictly necessary.

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?

There is no output schema, yet the description explains what comes back — one plain-English sentence per finding plus raw ledger facts — and fully covers the payment flow and the tool's non-executing nature. Nothing needed to invoke or interpret it correctly is missing.

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 the single address parameter, so the schema already documents it fully. The description reinforces the r... format via the endpoint example but adds no semantics beyond that; baseline 3 applies.

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+resource — determining who can move money out of an XRPL wallet — and enumerates the exact permission surfaces covered (master key, regular key, signer list, permission delegations, checks, channels, escrows, offers, tickets). This distinguishes it cleanly from siblings like check_xrpl_score or precheck_payment.

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?

Gives clear context: it is a paid x402 call returning the payment resource rather than running the check, and names the alternative for people who just want the result (the free page at xrplhub.io/permissions). It does not explicitly say when to prefer this over sibling check_* tools, so it falls short of full when/when-not routing.

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?

The description transparently states that every call persists an immutable Merkle-anchored snapshot, which is a side effect an agent should know. It also clarifies the limitation of 'no-loans-ever' (not proof of none) and the risk of borrowers erasing defaults. However, it does not explicitly state whether the tool is read-only or has any destructive capabilities, though the snapshot mention implies a write. The description is largely transparent about behavioral nuances.

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-structured. It front-loads the main purpose, then provides important caveats, return value hints, and operational notes. All sentences contribute value—some are warnings, some explain state meanings, and some clarify the mainnet status. No fluff or redundancy.

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 covers all essential context: what the tool does, what it returns (outstanding by asset, loan count, etc.), the meaning of disposition states, mainnet status, and a disclaimer. It also mentions the free pricing. Given there is no output schema, the description compensates by listing return fields. No critical missing information for an agent to decide to call this tool.

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 parameter 'borrower' is described with details: XRPL classic address format (r..., 25–35 chars) and required status. This matches the schema. The description adds contextual value by explaining the address format and the required constraint, but there is only one parameter and no enums or nested objects, so the coverage is adequate. A small deduction because the description does not elaborate on possible edge cases (e.g., invalid address handling), but it is clear enough.

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 the tool's purpose: to retrieve a borrower's total XLS-66 lending exposure across all loan brokers. It specifies the resource (borrower exposure data) and the action (get). It also differentiates itself from a sibling tool (get_lending_history) by focusing on aggregate exposure across brokers, which is distinct.

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 provides explicit guidance on when to use this tool: when needing total lending exposure across all brokers. It also includes important caveats about XLS-66 not being enabled on mainnet, the meaning of 'disposition' values, and the fact that deletions can erase default evidence. This is actionable guidance for an agent.

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 burden. It discloses the data source (append-only exposure snapshots), the visibility limitation (loans before first observation are invisible), the behavior for deleted loans (shown as vanished with everDefaulted true), and the observationWindow concept. It also mentions 'Free, no signup' as a practical access trait. This is thorough and transparent.

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 long but each sentence contributes meaning. It front-loads the core purpose, then explains per-loan details, an example, the observationWindow, and the parameter. It is structured logically and avoids fluff, though it could be slightly more compact without losing important nuance.

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 tool with no output schema, the description explains the output fields, the observationWindow, and the edge case of deleted loans. It gives the agent enough to know what to expect and how to interpret results. Missing error cases are minor and not critical for correct 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 describes the borrower parameter as an XRPL classic address (r...), and the description repeats this without adding new meaning. It does not elaborate on formatting, validation, or any edge cases. Since schema coverage is 100%, the description adds minimal value beyond restating the parameter.

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 exactly what the tool does: returns the complete observed loan history for a borrower, including deleted loans, with specific fields like first/last ledger, status, and flags. It is distinct from other lending tools by emphasizing the historical, append-only nature and the 'credit file' concept. The verb 'get' plus the resource 'lending history' is clear and unambiguous.

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 clear context that this is for historical loan data, especially for loans deleted from the ledger, which is a unique use case. It implies when to use it (when you need the full credit file) but does not explicitly name alternatives like get_lending_exposure or state when not to use it. The context is strong, but no explicit exclusions or alternative routing is given.

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 burden, and it does so well: it says the tool has no parameters, is free, is not the subscription mechanism, and offers no recommendation or probability of default. It also discloses watcher categories and delivery mechanics, giving the agent a realistic model of the service without overstating side effects.

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 information-dense and front-loaded with its purpose, but it is a single long run-on passage that would be easier for an agent to parse as structured bullets. Every clause adds content, so it is not padded, but the structure is not ideal.

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 no output schema, the description covers the key contents an agent needs: what is monitored, delivery mechanism, plan limits, capacity constraints, consumer-use restrictions, limitations, and the subscription endpoint. The phrase 'and the endpoints' is slightly vague, but enough is included to make the tool usable.

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?

There are no parameters, so the schema leaves nothing to document; the description explicitly confirms 'No params.' This matches the baseline for a zero-parameter tool and adds no confusing parameter information.

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 resource: 'Describe XRPLHub's continuous-monitoring service' and immediately states the decision it supports. It also distinguishes itself from the subscription endpoint by saying 'Subscribing needs an API key over HTTP (POST /api/monitor/subscribe), not this tool.'

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 gives clear context for when this information is relevant ('so an agent can decide whether to use it') and explicitly routes subscription actions away from the tool to the HTTP endpoint. It clarifies the service is advisory only ('never a replacement; no recommendation, no probability of default'), though it does not name sibling tools as alternatives.

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?

Even without annotations, the description fully discloses behavior: it returns payment resource details, includes a Merkle-anchored attestation, and explicitly states what it does NOT return (no recommendation). Cost and endpoint are also transparent.

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 in the description adds value: purpose, contents, exclusions, cost, endpoint, alternatives, and parameter format. No fluff or redundancy.

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?

Comprehensive for a paid, special-purpose tool. Covers purpose, components, payment details, endpoint, relationship to free siblings, and the single parameter. No critical operational details are missing.

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 covers the only parameter with a description matching the tool's mention of 'r...' format. Description adds no new semantic information beyond the schema, so baseline applies.

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?

Clearly states the tool returns the full underwriting-inputs bundle for an XLS-66 decision, listing specific components. Also distinguishes from sibling tools by noting free alternatives for some data.

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 notes this is a paid x402 call with cost and endpoint, states there is no free tier or API key, and directs users to get_lending_exposure and screen_address_ofac for free components. No ambiguity about when to use this 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 full behavioral burden and does so thoroughly. It discloses that the signature is an HMAC under a key only XRPLHub holds, that the result is XRPLHub's own attestation not independently verifiable proof, that the buyer need not control the wallet, that the first call returns a payment request valid 90 days, and that the second call returns certId and verifyUrl.

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 every sentence earns its place: purpose, trust model, call flow, parameters, and auth requirement. It is front-loaded with the primary purpose and proceeds logically through caveats and sequencing. The parameter sentence is compact and does not 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?

For a two-step, paid credential tool with no output schema, the description fully explains the sequence, return values (payment request, then certId/verifyUrl), fee (1 XRP or 1 RLUSD), validity period, trust model, and the fact that no signup is required. Missing edge cases like invalid wallet or expired uuid are minor against this level of completeness.

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% and the description reinforces roles by noting wallet_address format ('r...'), currency default, and uuid for the second call only. It adds the explicit constraint that the second call must reuse the same wallet_address together with the returned uuid, which goes beyond the schema's individual parameter descriptions.

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 resource: 'Get a certificate of a wallet's XRPLScore, signed by XRPLHub, with the score computed fresh at issuance.' This clearly distinguishes the tool from siblings like check_xrpl_score (score checking) and verify_attestation (verification) by focusing on issuance of a paid, signed 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 provides a clear usage context: a two-call flow, payment amount and validity, parameter roles, and 'No signup.' It even hints at when not to use the tool for verification ('counterparty checks it by asking XRPLHub's verify URL'). However, it does not explicitly name sibling alternatives or state exclusion conditions, so it stops short of full when/when-not 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, the description carries the full burden, and it discloses a lot: paid x402 call at $0.03 in USDC on Base or RLUSD on XRPL, the exact endpoint, and critically that the tool returns the payment resource rather than running the check. Missing auth/prerequisite and failure handling, but this is well above the no-annotation baseline.

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?

Front-loaded with the purpose and verdict shape, then cost/endpoint, then the crucial 'does not run the check' caveat. The closing param enumeration duplicates the input schema and is the one partly wasteful sentence.

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?

No output schema exists, so the description must convey returns, and it does specify the three-way verdict plus its components (score, sanctions with receipt, age/flags, rejection reasons). It does not describe the returned resource's structure or how to redeem the verifiable receipt, leaving a modest gap.

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 every parameter including the 'from' Deposit-Authorization explanation is already documented in the schema. The description's trailing param list largely restates the schema, adding the currency enum inline but nothing the schema does not already convey.

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+resource ('precheck payment') and enumerates the composite scope: XRPLScore, sanctions screen, account age/flags, and ledger-level rejection reasons. It clearly resolves the ambiguity that it returns a payment resource rather than performing the check. It does not explicitly name which sibling (check_xrpl_score, screen_address_ofac) it supersedes, so it stops short of 5.

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?

'Before your agent pays an XRPL address' gives a clear trigger condition, and the note that it returns the resource to call (not the check) tells the agent a follow-up invocation is required. There is no explicit when-not or named alternative among the many sibling check_* tools, so it falls short of 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 burden and delivers: it enumerates the pre-flight validations (destination existence, destination tag, Deposit Authorization, RLUSD trust line, sender balance + fee), states it refuses failing batches, declares the tool is FREE and never signs (non-custodial), and warns about sequence-number ordering.

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?

Front-loaded with the core purpose and one dense paragraph with little waste, though it packs validations, pricing, custody, and sequencing into a single long sentence chain, making it slightly heavy to parse.

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 states what is returned (an UNSIGNED Batch transaction plus a Xaman sign link) and covers the operator model, validation behavior, and ordering constraint. Nothing essential for correct invocation is missing.

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 only 50%, so the description must compensate. It supplies the recipient count bounds (2–8), the significance of destination tags and currencies (XRP/RLUSD trust line handling), and the paying-account role, adding real meaning beyond the raw schema 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?

States a specific verb+resource+scope: 'Pay 2 to 8 XRPL addresses with ONE signature, all or nothing.' It binds the tool to the XRPL Batch / tfAllOrNothing feature and clearly frames it as a batch-payment preparation step, which distinguishes it from single-payment siblings like precheck_payment.

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?

Gives clear context for when this applies (one-signature multi-payment, all-or-nothing, checked against the live ledger) and a sequencing constraint ('before sending any other transaction from that account'). It does not name the specific alternative (e.g. precheck_payment) or an explicit when-not-to-use, so it stops short of the full 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 fully carries the burden. It transparently discloses the nature of the output (a receipt attesting to process, not ground truth), clarifies that a 'no match' is not a statement of being clean, and includes legal disclaimers. It also conveys the operation is non-destructive (compare and receive receipt) and free.

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 excessively verbose and repetitive. Key caveats are stated multiple times (e.g., 'not legal or compliance advice', 'NOT a statement that the address is clean'). It could be condensed into a few concise sentences without losing meaning, so it scores below average.

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 the tool has no output schema, the description compensates by clearly enumerating return fields (queryId, list, result, statement). It also includes operational details like the terms of service and cost (free), 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?

The schema already provides full coverage of the single 'address' parameter, including type, format, and requirement. The description adds no substantive meaning beyond the schema, merely restating 'Params: address (r..., required)', so it meets the baseline of 3.

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 the tool's purpose: comparing one XRPL address against an OFAC SDN list snapshot and returning a receipt. It also specifies the exact scope (OFAC SDN only, no EU/UK/UN lists), which distinguishes it from potential sibling tools.

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 implicitly guides usage by specifying the scope (OFAC SDN only) and directs users to verify the receipt later with 'verify_attestation'. However, it does not explicitly name alternative tools for non-OFAC screenings, though the sibling list includes other tools.

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 burden of explaining behavior. It states the application is reviewed by a person, not automated, and that it returns a grant id and status. It does not mention potential side effects like whether submission guarantees approval or if funds are held, but the manual review process is transparently described.

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 reasonably concise and front-loads the core purpose, eligibility, and human review process. However, it includes a 'Params:' section that largely duplicates the input schema, which adds minor redundancy but does not become overly verbose.

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 covers the application context, eligibility, review process, and expected return value (grant id and status). Since there is no output schema, the return information is useful, though not detailed. It is complete enough for an agent to understand the tool's role and basic expectations.

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 description adds little beyond the schema. It repeats the category and amount constraints but omits the optional currency parameter from its inline param list. The schema already documents all parameters accurately, so the description provides no meaningful extra parameter-level meaning.

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 the tool's purpose: applying for a community micro-grant from the XRPLHub treasury, with eligible categories and amount range. It is easily distinguished from sibling tools like donate_to_community_fund because it is explicitly about applying rather than donating.

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 provides clear context on how the tool is used: it is for grant applications, lists eligible spending categories, and notes that a human reviews every application with no automated triage. It does not explicitly name alternative tools or state 'do not use when', but the purpose and review process are clear 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?

No annotations are provided, so the description carries the full burden. It explains the verification process step-by-step (rebuild leaf, fold proof, confirm root in MemoData) and mentions the pending status before the daily anchor runs. This fully discloses the tool's behavior without relying on annotations.

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 then provides necessary technical details about verification steps and the pending state. While somewhat verbose, the detail is directly relevant and the structure flows logically from purpose to method to edge case.

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 fully equips the agent to understand what to expect: it lists all output components (canonical leaf, Merkle proof, anchor tx hash, ledger close time, SHA-256 of source data) and explains the verification flow. It also covers the pre-anchor edge case. Without an output schema, this level of detail is 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?

The schema description for query_id already states it is the queryId from screen_address_ofac or get_lending_exposure. The tool description repeats this exact information, adding no new semantic meaning. Since schema coverage is 100%, the baseline score of 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 clearly states the tool's purpose: given a queryId from screen_address_ofac or get_lending_exposure, it returns all data needed to verify a receipt without trusting XRPLHub. It specifies the exact output components (canonical leaf, Merkle proof, anchor transaction hash, etc.), making the function unambiguous and distinct from sibling tools.

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 implicitly indicates when to use this tool: whenever a receipt from the two named source tools needs verification. It mentions the prerequisite queryId and the workflow of rebuilding the leaf, folding the proof, and checking the anchor transaction. It does not explicitly contrast with alternatives, but the references to the sibling tools provide clear context.

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?

The description indicates that the tool returns data and is 'free, no signup', but it does not explicitly state whether it is read-only, what happens on error, or whether it performs any state-changing operations. Since no annotations are provided, the description carries the full burden of behavioral disclosure and does not fully meet it.

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 overly verbose and repetitive, restating the same idea of the on-ledger anchor and the reproduction/checking workflow multiple times. It could be condensed to a few clear sentences without losing meaning, and the long trailing explanation makes it less 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?

The description covers what the tool returns, why it matters, and how the returned root can be used to verify published data. There is no output schema, so the explanation of return values is important and is provided. It does not discuss error cases, but for a parameterless read-style verification call the core context is sufficiently 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?

The input schema is empty and the description explicitly confirms 'No params', so there are no parameter details missing. This is essentially ideal for a parameterless tool, though it adds no extra semantic depth beyond confirming that no arguments are 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?

The description clearly states the tool's purpose: to get the latest on-ledger anchor of the MPT registry and return the Merkle root plus associated metadata. It specifies the exact resource and action, and the output list makes it unambiguous what the tool does. The name 'verify_mpt_registry' aligns well with the described behavior.

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 implies a verification use case by mentioning that you can reproduce the root from published data and check that rows match the anchor, but it never explicitly says when to use this tool versus alternatives like verify_attestation or search_mpts. It also does not state conditions under which this tool should be preferred, so guidance is mostly implicit.

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