Asteroid XRPL Hub

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

Annotations already establish readOnlyHint, idempotentHint, and closed-world behavior. The description adds substantial return-level context: availability states, freshness, provenance, schema, limitations, schema version, and canonical asset identity.

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?

It is a single front-loaded sentence that begins with the action and packs in the returned fields without repetition. It is long and somewhat list-heavy, but each element is informative.

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, so the description must carry the burden of explaining return contents. It does so thoroughly, covering the entry points, capability catalogue, per-tool states, freshness, provenance, schema, limitations, schema version, and asset identity.

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 takes zero parameters, so the baseline is 4. The description cannot add parameter semantics because there are no parameters to describe.

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 gives a specific verb and resource: returns authoritative ASTEROID XRPL entry points and a full capability catalogue. It also enumerates the per-tool states and metadata returned, making clear how this discovery tool differs from the get_*/verify_* 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 implies usage as a discovery entry point for ASTEROID capabilities, but does not explicitly state when to use this tool versus calling sibling data tools directly. No when-not or alternative-based guidance is provided.

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?

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so safety is covered. The description adds meaningful context beyond them: the data is 'immutable'/'canonical' and explicitly excludes changing ledger metrics, and metadata is 'claim-status-separated', which tells the agent this is static identity data rather than live state.

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?

Two dense sentences, front-loaded with the primary return content and followed by a scoping exclusion. Every clause carries information; 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?

With no output schema, the description must describe the return payload, and it does so concretely (identity fields plus project metadata, with a stated exclusion). For a zero-param, read-only tool with full annotation coverage, nothing an agent needs 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the 4 baseline applies. No parameter guidance is needed or missing.

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 ('Returns') and resource ('immutable canonical ASTEROID identity') and enumerates the returned fields (network, issuer, 160-bit currency code, token identifier). It implicitly distinguishes itself from metric/state siblings like get_market_state and get_token_stats by emphasizing immutability, but never names a sibling explicitly.

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 phrase 'No changing ledger metrics' hints at when-not to use this tool (i.e., for live metrics reach for the state/stats siblings), but there is no explicit when-to-use statement or named alternative. Usage is only implied.

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?

Annotations already declare readOnlyHint/openWorldHint, so the safety profile is covered. The description goes further with substantive epistemic caveats: escrow objects are ledger-verified while the treasury role is only an owner-confirmed declaration, and an escrow does not establish who controls the destination after release. That is real behavioral context an agent could otherwise over-assume. It stops short of noting freshness/pagination behavior for an openWorld read.

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?

Two sentences, front-loaded with the returned payload and followed by the caveat; nothing is wasted. The first sentence is dense and slightly run-on, but every clause carries information an agent needs.

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?

With no output schema, the description carries the full burden of explaining the return value, and it does so field by field (amount, destination, finish-after, cancel-after, locked/releasable/expired state, total escrowed, next unlock) plus the interpretive limits. Nothing an agent needs to call and read 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?

The tool takes zero parameters, so the schema-side burden is nil and the baseline is 4. The description correctly adds no parameter discussion, which 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 gives a specific verb+resource ('Ledger-indexed schedule of ... treasury ASTEROID escrows') and enumerates what each escrow object contains, so the agent knows this returns per-escrow detail. It does not explicitly contrast itself with the nearby get_escrow_stats, leaving the schedule-vs-aggregate boundary to inference rather than stating it.

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?

There is no statement of when to reach for this tool versus get_escrow_stats or the verification tools, and no prerequisites or exclusions are given. The agent must infer usage from the noun 'schedule' alone.

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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the read-only safety profile is covered. The description adds genuinely useful caveats beyond the schema: the treasury role is an owner-confirmed declaration, not a verified fact, and escrow existence does not establish who controls the destination account. That interpretive framing is real added value, though it stops short of describing pagination or output shape.

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 deprecation notice and alternative are front-loaded in the first clause, which is the most important routing information. Subsequent sentences are dense but each carries content (scope, caveats). Slightly long, but 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?

With no output schema, the description carries the burden of describing returns and does so field-by-field (amount, unlock date, cancel date, total escrowed, share of supply). Combined with the deprecation routing and the control caveat, an agent has everything needed to decide and call 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 takes zero parameters, so the baseline is 4 and there is nothing for the description to disambiguate. The description instead specifies the returned field semantics, which 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?

States a specific resource and scope: time-locked project-declared treasury ASTEROID escrows on the XRP Ledger, with the exact fields returned (amount, finish-after, cancel-after, totals, share of supply). It also names the sibling get_escrow_schedule and how it differs, so an agent can distinguish the two without opening schemas.

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 marks itself deprecated and routes the agent to get_escrow_schedule, explaining that the successor adds per-escrow locked/releasable/expired state. This is a clear when-not-this-tool plus a named alternative, leaving nothing to inference.

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?

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=true, idempotentHint=false), so the bar is lower. The description adds genuine behavioral context: it runs against 'one validated ledger,' discloses whether 'the marker chain was exhausted' (truncation/pagination completeness), and promises the 'exact counting methodology,' which is valuable disclosure beyond structured fields.

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?

Two sentences, front-loaded with the enumeration of returned metrics before the interpretive caveat. No filler; each clause contributes (returned fields first, then semantic warning).

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-param, read-only tool with no output schema, the description enumerates the return contents and caveats interpretation, which is close to complete. Minor gap: it doesn't state a ledger-selection mechanism even though it operates on 'one validated ledger.'

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?

With zero parameters, the baseline is 4. There is nothing to document, and the description does not attempt to introduce undocumented 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?

States a specific verb+resource scoped precisely: a 'complete trust-line enumeration of the ASTEROID issuer on one validated ledger,' naming exactly the outputs (total trust lines, non-zero balance lines, marker exhaustion). It implicitly separates itself from holder-count siblings like get_token_stats by clarifying 'a trust line is not a person,' though it does not name a sibling explicitly.

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 through the caveat that trust lines != holders, which tells the agent when this metric is (and isn't) appropriate. However, no explicit when-to-use or alternative selection (e.g., vs get_supply_state or get_token_stats) is provided.

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?

Annotations already cover the safety profile (readOnlyHint, openWorldHint, idempotentHint), so the bar is lower; the description still adds real context by stating the data is 'ledger-indexed' (a snapshot, not live), clarifying the fee is a protocol LP-vote fee rather than a token tax, and explaining how the accessibility verdict is derived from master/regular keys and signer list.

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?

A single dense sentence that is front-loaded with the resource identity, which is appropriate. It is packed tightly (four commas plus parenthetical) but nearly every clause maps to a returned field, so little is wasted.

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?

With no output schema, the description has to carry return-value semantics, and it does so by naming the pooled reserves, LP supply, fee, and per-account fields. What is missing is any mention of pagination, freshness, or filtering scope, but for a zero-parameter snapshot tool this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4.

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?

Names a specific verb+resource (ASTEROID/XRP AMM state) and enumerates exactly what it returns: pooled reserves, LP supply, trading fee, per-account LP share and accessibility verdict. The closing 'Not a quote' explicitly separates it from quote-oriented siblings like get_swap_quote.

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 'Not a quote' clause gives one useful exclusion against get_swap_quote, but there is no positive statement of when to prefer this over the closest sibling get_liquidity_stats, nor any prerequisites. Guidance is implied rather than explicit.

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?

Beyond the readOnly/openWorld/idempotent annotations, it discloses that the data is live ("Current"), that the trading fee is a protocol pool fee set by LP votes and "can change at any time," and flags its deprecated status. It doesn't cover rate limits or exact freshness guarantees, but the added behavioral context is 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 deprecation warning is correctly front-loaded and the trade fee unit gotcha is worth stating, but the field-by-field explanation of tradingFeeUnits/tradingFeePct/tradingFeeBps is dense and somewhat repetitive. Still, each clause carries information relevant to interpreting the response.

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?

With no output schema and no parameters, the description carries the full burden of explaining the return payload, and it does so thoroughly (pooled amounts, LP supply, fee units and percentage, locked vs community split). An agent has everything needed to interpret the result and avoid misuse as a price.

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 takes zero parameters, so there is no parameter semantics to explain; the 4 baseline applies. The description appropriately spends its space on output semantics instead.

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?

It names the specific resource and scope ("Current ASTEROID/XRP AMM pool data: pooled XRP and ASTEROID, LP token supply, trading fee, locked vs community LP split"), so an agent knows exactly what it returns. It also explicitly distinguishes itself from the sibling get_liquidity_state by marking itself deprecated in favor of it.

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 an explicit migration directive ("Deprecated — use get_liquidity_state") and a hard exclusion ("This is not a quote and must not be used to price a swap"). Both when-to-use (only for current pool stats) and when-not-to-use are covered.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real value beyond them by disclosing the response envelope ('per-section provenance and degraded codes'), that results are ledger-indexed and live, and that the call is pure observation with no side effects. It does not explain why idempotentHint=false (time-varying live state), leaving one annotation gap unaddressed.

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?

Two sentences, front-loaded with the returned sections and closed by the boundary statement. The first sentence is a dense list but every enumerated section maps to real output content, so little is wasted; slightly tighter phrasing could improve readability.

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?

With no output schema, the description carries the burden of describing returns, and it does so by enumerating the snapshot sections and the provenance/degraded-code envelope. Combined with annotations covering the read-only profile, an agent has enough to call it correctly; the meaning of the degraded codes is the only unresolved detail.

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 takes zero parameters, so per the rubric the baseline is 4. The description correctly introduces no argument semantics because there are none to define.

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 resource (a composite, ledger-indexed snapshot of ASTEROID) and enumerates every section it returns: supply breakdown, AMM liquidity and trading fee, LP-lock accessibility, treasury escrows, and trust-line/holder counts. The 'composite' framing distinguishes it from the granular siblings (get_supply_state, get_liquidity_state, get_holder_distribution) without the agent needing to open schemas.

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 explicit when-not guidance: 'not a quote, not a market evaluation and not transaction preparation,' which routes quote/prep needs toward siblings like get_swap_quote. It stops short of stating the positive case (use this when you need all sections in one call rather than several granular getters), so the guidance is clear but not fully symmetric.

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?

Annotations already establish readOnly, idempotent, openWorld, so the bar is lower, yet the description still adds real context the schema cannot: the data is independently sourced from a third-party market API rather than a ledger read, and it is indicative/non-executable with no slippage or depth modelling. That sourcing and reliability caveat is exactly the kind of behavioral disclosure an agent cannot get from structured fields.

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 tight sentences with the payload front-loaded and caveats following, no filler. The opening fragment 'Legacy-available.' is cryptic shorthand that costs a little clarity for its brevity.

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?

With no output schema and no parameters, the description does the heavy lifting well by enumerating what comes back (30-day daily series, spot price, 24h/30d deltas) and flagging the third-party sourcing. It is nearly complete, with the only gap being what 'Legacy-available' implies about availability or deprecation.

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 takes zero parameters, so the baseline is 4. The description spends its words on the return payload (daily observations, current price, 24h and 30d change) rather than parameters, which is the right allocation, though 'Legacy-available' is an unexplained qualifier that could confuse expectations.

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 resource (ASTEROID daily USD price observations) with explicit scope: last 30 days plus current price and 24h/30d change. It partially differentiates from siblings by ruling out the executable-quote path ('not a quote, not executable'), though it never names get_swap_quote, get_market_state, or get_token_stats directly.

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 only implied: 'not a quote, not executable, no slippage or depth modelled' steers an agent away from treating this as execution data, but there is no explicit statement of when to call this versus get_swap_quote or get_market_state. The unexplained 'Legacy-available' prefix adds ambiguity rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the data is 'static public reference info' and the tool is legacy, which tells the agent not to treat it as a live/authoritative source.

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?

Two sentences, no filler, and the alternative-tool routing is placed last where an agent will see it. The long enumerated field list is dense but each item is informative; opening with the unexplained 'Legacy-available' is slightly awkward front-loading.

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?

With no output schema, the description carries the burden of describing returns and does so thoroughly via the field enumeration, plus a cross-reference to get_asset_identity. It leaves 'legacy-available' undefined and doesn't say whether the data can be stale, which is the one remaining gap for a reference-data 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?

Zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to clarify or obscure. The returned-field list is arguably return-value documentation rather than parameter semantics.

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 resource (static public reference info about the ASTEROID XRPL project) and enumerates exactly what it returns: issuer address, currency code, wallet roles/claim status, website, where to buy, socials, disclaimer. It also explicitly distinguishes itself from get_asset_identity, so an agent can separate it from the 14 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?

Gives a clear routing rule: 'For canonical machine identity prefer get_asset_identity,' which is exactly the when-to-use-this-vs-alternative guidance needed. It also flags 'Legacy-available,' hinting at deprecation status, but never states when this tool should still be called or what 'legacy-available' means operationally.

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 annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: amounts are exact decimal strings, unreadable values are null with a degraded code, and values are never returned as zero. It does not cover auth or rate limits, but that is not required given the annotation coverage.

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 adds key data-quality details in two efficient follow-up sentences. Every sentence earns its place and there is 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?

With no output schema, the description carries a larger burden and does describe the returned supply dimensions plus null/degraded handling and exact decimal formatting. It stops short of fully explaining the response structure or the meaning of degraded codes, but it is substantially complete for a zero-parameter read 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 tool takes zero parameters, so there are no parameter semantics to document. The schema has no properties and no parameter descriptions are needed, making the baseline 4 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 states a specific resource and verb: retrieving ledger-indexed ASTEROID supply, with a precise list of included metrics. However, it does not differentiate this tool from sibling tools such as get_token_stats or get_escrow_stats, so the agent must infer the boundary from the name alone.

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 explains what data is returned but gives no guidance on when to use this tool instead of alternatives. There is no mention of prerequisites, exclusions, or the sibling tools that might cover overlapping supply or token statistics.

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?

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description goes well beyond them: it discloses that the quote is live-pool, non-executable, unsigned, path-finding-free, excludes network/transfer fees, and enumerates the returned fields (amount in/out, pool fee, spot/effective price, price impact, utilisation, slippage bounds) as exact decimal strings at a validated ledger index. This is unusually rich behavioral context and supports the idempotentHint=false (live state changes).

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?

Two dense sentences with the core purpose front-loaded and the critical caveat (indicative, non-executable, no keys) clearly separated. It is longer than minimal but each clause carries distinct information; only the enumeration of return fields could be trimmed if an output schema existed.

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, so the description correctly enumerates the return fields and their format (exact decimal strings at a stated ledger index). Combined with the safety/exclusion disclosures and full schema parameter coverage, an agent has everything needed to call and interpret 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?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: it clarifies that direction supports 'either direction' and side supports 'an exact input or an exact output', and that slippageTolerancePct is optional and only used to derive a bound. This supplements the schema rather than merely restating 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?

Names a specific verb+resource (get_swap_quote) and pins it to the live ASTEROID/XRP AMM pool, stating it covers both directions and both exact-in/exact-out modes. This is clearly distinguishable from the sibling read-only analytics tools (get_liquidity_state, get_market_state, etc.) that do not return a swap estimate.

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 for use and strong exclusions: 'INDICATIVE ONLY: it is not executable... models only the single AMM pool (no order books, no path-finding, no network or transfer fees), and this service never signs, submits or prepares a transaction.' It tells the agent when NOT to rely on it, though it does not name a sibling alternative for executable swaps.

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?

Annotations already establish readOnlyHint, openWorldHint, and idempotentHint. The description adds useful context beyond annotations: deprecation status, the replacement tool's advantages, the inclusion of escrowed tokens in total supply, and the caveat that wallet labels reflect owner-confirmed declared roles only.

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 deprecation warning and replacement recommendation, then proceeds to the stats returned and a caveat about wallet labels. Every sentence carries information relevant to an agent deciding whether and how to call the tool.

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?

With no parameters and no output schema, the description carries the burden of describing return values. It lists the key metrics and a wallet-label caveat, but does not fully specify formatting details such as whether values are exact decimal strings, degraded codes, or tied to a validated ledger index—though it implies those features belong to the replacement.

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, so the baseline is 4. There are no parameters to document, and the description does not need to add parameter semantics.

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 read operation and resource: current on-chain stats for the ASTEROID token on the XRP Ledger. It enumerates the exact metrics returned and explicitly names the sibling replacement, get_supply_state, making it easy to distinguish from alternatives.

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 first sentence directly marks the tool as deprecated and instructs use of get_supply_state instead. It also explains why the replacement is preferable by listing its validated ledger index, per-value claim statuses, exact decimal strings, and degraded codes.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that the comparison is field-by-field against a canonical record; it says nothing about mismatch handling, missing-record behavior, or what happens when the candidate is not on the expected network.

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?

Two sentences, zero waste: the verification action and its candidate inputs come first, and the 'symbol alone is insufficient' caveat follows as a tight warning.

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, so the description carries the burden of describing returns; 'field-by-field result' is directionally helpful but does not enumerate which fields are returned or what a negative verification looks like. Adequate, but a gap for a tool whose entire value is its comparison output.

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 each of the three parameters is documented with its role and requiredness, so the schema does the heavy lifting. The description restates the triple (network, issuer, currency code) without adding format guidance, e.g. the 160-bit hex form the schema mentions.

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 (compares/verifies) and resource (candidate network/issuer/currency against the canonical ASTEROID identity) and notes the return shape ('field-by-field result'). It does not, however, contrast itself with the nearby sibling get_asset_identity, so an agent must infer the split between reading an identity and verifying one.

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 stated: the caution that 'the display symbol ASTEROID alone is never sufficient verification' hints at when this tool is needed, but no alternative (e.g. get_asset_identity or discover_asset) is named and no when-not condition 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?

Annotations cover the safety profile (readOnly, openWorld, non-idempotent), and the description adds real value beyond them: it specifies that verification is live and anchored to a validated ledger, and warns that a closed signing path is an observation at one ledger rather than a permanence guarantee. It also notes the account role is an owner-confirmed declaration, which qualifies the reliability of the verdict.

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?

Two sentences with no filler; the enumeration of outputs is front-loaded and the caveat follows. The first sentence is dense with clauses but each clause carries distinct 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?

With no parameters and no output schema, the description carries the burden of explaining what comes back, and it does so (balances, share, pro-rata values, control assessment, verdict). The ledger-pinning caveat also sets expectations correctly. Only the absence of any sibling/timing guidance keeps it from full 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?

Zero parameters and 100% schema coverage, so the baseline is 4. The description necessarily adds nothing about inputs because there are none to describe.

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 (verify) and resource (LP-lock accessibility for the ASTEROID/XRP AMM), and enumerates the concrete outputs: LP balance, share of supply, pro-rata implied XRP/ASTEROID, per-account control assessment, and an overall verdict. It is distinguishable from siblings like get_liquidity_state and get_liquidity_stats, though it never names them or explicitly contrasts the distinction.

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 context is implied (this is the live LP-lock verification tool) but there is no explicit when-to-use, when-not-to-use, or alternative routing versus get_liquidity_state/get_liquidity_stats. The caveat about closed signing paths is interpretive guidance rather than invocation guidance.

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