N9T2 XRPL Agent Gateway

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

Annotations only give generic hints (readOnlyHint=false, idempotentHint=false, openWorldHint=true); the description adds the substantive facts an agent needs: the call is free, it creates a record but moves no funds, it returns quote_id, exact payment instructions (amount, asset, network, pay_to, expiry), a 1.45 XRP-equivalent fee, and an estimated destination amount. It also discloses the per-asset self-serve caps, which the annotations cannot express. No contradiction with readOnlyHint=false since a quote record is still created.

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 'FREE' and the route scope, then returns, then behavior, then next step – a sensible ordering with no filler sentences. It is somewhat long and repeats the amount caps that already live in the schema, which is the only waste.

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 return-value burden and does so: it enumerates the returned fields and the fee. Combined with the workflow handoff to n9t2_bridge_submit_payment and the OTC escalation path, an agent has everything needed to call this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does add the fee-on-top rule and the caps/OTC escalation for source_amount, but it largely restates what the schema's own field descriptions already say, adding little new parameter 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?

States a specific verb ('Get a live, firm quote') plus the exact resource and scope ('move funds both ways between native XRP on the XRP Ledger and BTC on Bitcoin, BNB, USDT or USDC on BNB Chain (bsc), or USDC or ETH on Base (12 live routes)'). This cleanly separates it from siblings n9t2_bridge_submit_payment and n9t2_bridge_receipt, which are named or implied as distinct steps.

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 says creating a quote moves no funds, prescribes the workflow ('Next: customer approves and pays in their own wallet, then call n9t2_bridge_submit_payment'), and gives a when-not path: transfers above the self-serve caps go to the OTC desk at boss@n9t2.com. An agent knows both the next call and the escalation condition.

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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the call is free, the receipt is immutable and customer-safe, the exact condition that marks a transfer complete, and how a 404 should be read. It does not discuss rate limits or caching, but the added 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?

Three tight sentences with no filler, front-loaded with the most decision-relevant fact ('FREE') and then the resource and its fields. Every sentence earns its place by adding interpretation the schema and annotations do not carry.

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 returned fields. It also supplies the completion predicate and the 404 semantics, which are the two things an agent needs to act on the response. Nothing essential is missing for a single-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?

With a single parameter at 100% schema description coverage, the schema already documents quote_id. The description only restates that lookup is 'by quote_id' and adds no format, sourcing, or validation detail, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (read) and resource (immutable receipt for a bridge transfer) and enumerates exactly what the receipt contains: status, amounts, fee, route cost, and transaction hashes. This clearly separates it from siblings like n9t2_bridge_quote and n9t2_bridge_submit_payment, which act on the transfer rather than reporting on 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?

Gives real usage context: the 'FREE' tag signals no cost to call, the completion rule ('settled' + settlement.status 'completed') tells the agent how to interpret the result, and '404 means not ready yet' tells it to retry rather than treat it as an error. It stops short of explicitly naming alternative tools for pre-transfer or payment steps, so it is clear context without full alternative 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?

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, but the description adds substantial context beyond them: on-chain verification against exact amount, asset, recipient and expiry, execution via an exactly-once worker, and idempotent resubmission returning the existing record. It also warns that verification is not completion, which the annotations cannot convey.

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?

Four sentences, front-loaded with the cost signal ('FREE'), then the action, then verification semantics, then the follow-up. Every sentence carries distinct, non-redundant 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 2-parameter tool with no output schema, the description covers the full lifecycle: what is submitted, how it is verified, what happens on duplicate submission, and where to go next. Nothing an agent needs in order to invoke 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% and both parameters are documented in-schema (quote_id from n9t2_bridge_quote, hash must be real not fabricated). The description reinforces the 'real payment' requirement but adds no new syntax, format, or constraint beyond what the schema already supplies, 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 and resource: submit the transaction hash of the customer's real payment for a bridge quote. It clearly differentiates itself from n9t2_bridge_quote (which produces the quote) and n9t2_bridge_receipt (the follow-up), so an agent can place it in the bridge flow 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?

Gives clear ordering context by naming the follow-up tool ('follow up with n9t2_bridge_receipt') and by tying the input back to n9t2_bridge_quote. It also flags the cost ('FREE') and the resubmission behavior. It stops short of an explicit when-not clause, but the sequencing guidance is unambiguous.

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 destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: it does not construct, sign, submit or modify any transaction, and it discloses the result shape (candidate path alternatives plus source-amount information). Only the auth/rate-limit dimension is 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?

Three front-loaded sentences that each carry distinct information: purpose/scope, parameter semantics, routing to alternatives and follow-ups. Slightly dense but no filler or repetition.

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 3-parameter read-only discovery tool with no output schema, the description covers what it returns, what it deliberately does not do, and the correct follow-up tool. Nothing an agent needs in order to call 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 coverage is 100%, so the baseline is 3. The description still adds meaning beyond the schema by defining destination_amount as the exact amount the destination should receive and by clarifying the two accepted encodings in terms of intent rather than just types.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (read-only XRPL payment-path discovery) plus scope (source_account to destination_account) and explicitly distinguishes itself from n9t2_xrpl_get_book_offers. An agent can separate this from the other 17 siblings without opening a 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?

Explicit when-to-use ('when XRPL routing is needed between the source and destination accounts'), an explicit alternative with its own condition ('use n9t2_xrpl_get_book_offers for DEX order-book depth instead'), and a named follow-up tool (n9t2_xrpl_prepare_transaction) for the next step.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered structurally. The description goes beyond that by disclosing gateway rate limits, stating no transaction is submitted/modified, and enumerating the returned fields. It stops short of pagination or error behavior, so it is strong but not 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?

Two dense sentences with no filler, and the scope/return profile is front-loaded before the sibling routing. The return-field enumeration is slightly long but every clause carries 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 output schema, the description compensates by naming the returned fields (balance, sequence, owner count, flags, settings), and it covers the read-only/rate-limit behavior. Nothing an agent needs to call 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 coverage is 100% for the single parameter, so the schema already documents it. The description adds a format constraint ('must be a valid XRPL classic account address'), which is a modest but real addition; baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only XRPL current-account-state lookup for one account') and explicitly contrasts itself with named siblings. An agent can distinguish it from get_transaction, list_account_transactions, and get_ledger_data 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?

Gives both the selection condition ('Use this for current account state only') and the alternatives ('use n9t2_xrpl_get_transaction or n9t2_xrpl_list_account_transactions for transaction history, and n9t2_xrpl_get_ledger_data for raw ledger objects'). Nothing is left 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 already declare readOnlyHint, idempotentHint and destructiveHint, so the safety profile is covered. The description adds genuinely new context: it is a paid lookup, it does not modify the ledger, it is subject to gateway rate limits, and it returns native amm_info with pool balances, LP token supply, fee, auction slot and vote slots. That is meaningful behavior beyond what annotations convey.

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 front-loaded: purpose first, then pool identification, then ledger pinning, then return shape, then sibling routing. Every sentence carries information, though it is on the longer side.

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 compensates by enumerating the return fields (balances, LP supply, fee, auction slot, vote slots). Combined with the parameter model and rate-limit note, an agent has everything needed to call and interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the baseline, but the description adds real meaning by explaining the two alternative pool-identification paths (`amm_account` OR the paired `asset`/`asset2`), that `account` is optional context, and that ledger_hash/ledger_index pin the lookup. This reconciliation goes beyond the per-field schema text.

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 ('Read-only XRPL Automated Market Maker (AMM) state lookup for a specific pool') and explicitly distinguishes itself from two named siblings, n9t2_xrpl_get_book_offers and n9t2_xrpl_get_ledger_data. An agent can route to it 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?

It gives explicit alternatives and the conditions that select them: use this for AMM pool state, use get_book_offers for DEX order-book depth, use get_ledger_data for raw ledger-state objects. Nothing is left to inference about when to pick 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description's 'without modifying the ledger' is largely redundant with that. It does add genuinely new context, though: calls are subject to the configured gateway rate limits, and the result contains global book offers plus market-depth data. Pagination behavior beyond the limit cap is not 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?

Three sentences, all front-loaded, with the core purpose first and routing last. Slight redundancy: 'without modifying the ledger' restates what readOnlyHint already covers, which is the only sentence that does not fully earn its place.

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 compensates by stating that the result yields global book offers and market-depth data. Parameter meaning for the required nested currency objects is described at the intent level. What is missing is any hint of result shape or the depth/ordering of returned offers, which matters for a book-depth 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 description coverage is 100%, including descriptions for limit, taker_gets, and taker_pays, so the baseline is 3. The description adds mild framing (the two currency-spec objects define the two sides of the book; limit caps offers returned) but no format details or structure for the nested currency objects that the schema leaves as additionalProperties: true.

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 first sentence names a specific verb+resource (read-only order-book lookup) and the scope (a specific trading pair) in one line. It also names two siblings and the condition each covers, so an agent can distinguish it from n9t2_xrpl_list_account_offers and n9t2_xrpl_find_path without opening a 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?

The last sentence is explicit routing: 'Use this for global DEX order-book depth; use n9t2_xrpl_list_account_offers for one account's outstanding offers and n9t2_xrpl_find_path when you need payment-path discovery.' Both when-to-use and alternatives are stated, with no inference required.

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, destructiveHint=false and openWorldHint, so safety is largely covered; the description's "without modifying the ledger" is largely redundant. It does add genuinely new behavioral context, though: calls are subject to configured gateway rate limits, and the result is a computed exposure figure rather than raw ledger entries.

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 purpose and scope come first, followed by parameter behavior, then the safety/limits note, then the sibling exclusion — a sensible front-loaded order. It is dense with back-to-back clauses and slightly longer than needed, but no sentence is 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 read-only calculation tool with no output schema, the description covers what is returned (the calculated exposure), safety, rate limits, and the nearest alternative tool. It omits pagination/return-format detail and does not explain what a "strict" interpretation changes, which is a minor 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 the baseline is 3, but the description adds semantic intent beyond the schema text: hotwallet addresses are those whose balances "should be included in the calculation," and ledger_index "pins the calculation to a specific ledger." It does not, however, clarify strict's interpretation semantics beyond the schema wording.

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 ("issued-asset exposure calculation for one issuing account") and explicitly contrasts itself with the sibling tool n9t2_xrpl_list_account_lines. An agent can distinguish it from the other list_* / get_* siblings 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?

It gives explicit positive routing ("Use this for issuer-level issued-asset exposure") and an explicit exclusion with a named alternative ("do not use it for trust-line holdings of a single account, where n9t2_xrpl_list_account_lines is the appropriate tool"). It also explains the conditions under which the optional hotwallet and ledger_index parameters should be used.

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 readOnly, idempotent, non-destructive, openWorld, so the safety profile is covered. The description still adds real context beyond them: the default-to-current-validated-ledger behavior and that calls are subject to configured gateway rate limits. It does not detail response shape or error conditions, keeping it short of 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?

Front-loaded with the core purpose, then behavior, then routing. It is a single dense paragraph with little waste, though the middle sentence packs three clauses and the final 'use this for...' clause partly repeats the opening.

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 still tells the agent what comes back (ledger metadata plus optionally transactions) and how to control it. It stops short of describing pagination or the exact metadata fields, a minor gap for a read-only lookup.

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 the dependency the schema does not state: expand only yields full objects for transactions included via transactions=true. It also restates the omit-ledger_index default in operationally useful terms.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only XRPL ledger header and metadata lookup') and explicitly names the sibling it is not ('use n9t2_xrpl_get_ledger_data instead when you need raw ledger-state objects'). An agent can distinguish this from the other 18 siblings without opening a 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?

Gives an explicit when-to-use plus concrete conditions for each mode: omit ledger_index for the current validated ledger, pin via index/selector, set transactions/expand as needed. It also names the alternative tool and the exact condition that selects it.

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 destructiveHint=false, so safety is covered structurally. The description still adds real context beyond that: results are raw canonical entries, the ledger is not modified, large state queries should be paginated, and calls are subject to gateway rate limits — a genuine operational constraint the annotations do not convey.

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 verb and resource, then the parameter guidance, then the sibling disambiguation last — a sensible ordering. It is a dense, semicolon-chained single paragraph, but every clause carries distinct information rather than padding.

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 still characterizes the return (raw canonical ledger-state entries) and covers pagination, rate limits, and the alternative tool. For a three-parameter read tool with full annotation coverage, nothing an agent needs to invoke 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 coverage is 100%, so baseline is 3, but the description adds semantics the schema lacks — notably that omitting `ledger_index` falls back to the default ledger, and that `marker` must come from a previous response. That default-behavior and pagination-chaining context goes beyond the field 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?

States a specific verb+resource ("Read-only XRPL raw ledger-state lookup for a ledger") and explicitly distinguishes itself from the nearest sibling, n9t2_xrpl_get_ledger, which is scoped to headers and transaction-list metadata. An agent can route between the two without opening either 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?

Gives explicit operational guidance: omit `ledger_index` for the default ledger, supply it to pin a lookup, use `limit` to cap results, and pass `marker` to continue pagination. It also names the alternative tool and the condition that selects it, 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 already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the useful 'no parameters' and 'use as a pre-flight health check' context, but also redundantly restates 'does not modify the ledger', which duplicates the annotations rather than adding new behavior.

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 purpose and routing before the caveats, and most sentences earn their place. Minor redundancy in restating non-mutation and re-explaining ledger variants keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description responsibly indicates what the result contains (node/server status and validated-ledger information). For a zero-param read tool this is essentially complete, with only minor room to describe the freshness fields more concretely.

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 is 4. The description reinforces this with 'requires no parameters', matching the empty schema without introducing confusion.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only XRPL server_info lookup') and scopes it to node health, server state, and validated-ledger status. An agent can distinguish it from ledger/transaction siblings without opening the 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?

Gives explicit when-to-use guidance ('before interpreting ledger-dependent results when node health or freshness matters') and names two alternatives with their distinct purposes (get_ledger for metadata, get_ledger_data for raw state). Nothing is left 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 already declare readOnlyHint, idempotentHint, destructiveHint, and openWorldHint, so the safety profile is covered. The description adds a useful rate-limit disclosure ('calls are subject to the configured gateway rate limits') and reinforces non-modification, though it does not characterize return format or error behavior.

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?

Four purposeful sentences with the core identity front-loaded. Parameter guidance, result behavior, and alternative routing are all included without 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 simple read-only lookup with rich annotations and full schema coverage, the description is nearly complete. The only minor gap is that no output schema exists and the description does not characterize the returned transaction data structure.

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 adds conditional meaning for binary ('set binary=true only when binary-encoded transaction data is required, otherwise use the normal transaction representation') beyond the schema's plain boolean description.

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 ('Read-only XRPL transaction lookup') and resource ('one canonical transaction hash'), and explicitly distinguishes itself from the account-wide sibling. An agent can identify the tool's scope without opening the 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?

Provides explicit when-to-use guidance ('Use this when the transaction hash is already known') and names the alternative tool for account-wide history ('use n9t2_xrpl_list_account_transactions instead'). It also clarifies the conditional use of the binary parameter.

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, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description still adds real value beyond them: 'without modifying the ledger' and, notably, 'calls are subject to the configured gateway rate limits' — an operational constraint not present in the annotations. It does not describe failure modes or result shape in depth, which keeps it below 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?

Front-loaded with purpose, then parameters, then behavioral notes, then sibling routing — a logical order with no filler sentences. It is on the denser end for a 5-parameter lookup, but every clause carries information and nothing is repeated from the schema verbatim.

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, and the description covers the essentials an agent needs: default scoping (source), pagination via marker, limit default of 200, ledger pinning, and the rate-limit caveat. It stops short of describing the entry fields returned, which is a minor gap for a tool with no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds semantics the schema lacks: it clarifies that by default the account is treated as the channel *source* and that destination_account flips the filter to destination. That resolves genuine ambiguity about which role `account` plays, going beyond the schema's neutral wording.

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: 'Read-only XRPL Payment Channel lookup for one account', and explicitly names the sibling it is not (n9t2_xrpl_list_account_objects for generic ledger objects). An agent can distinguish it from list_account_objects, list_account_lines, and list_account_offers 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?

Explicit when-to-use: 'Use this for PaymentChannelCreate/Fund/Claim inspection', with an explicit alternative named for the generic case. It also routes each optional parameter to its purpose (destination_account to filter by destination, ledger_index to pin to a validated ledger, marker to continue pagination), so no selection decision is left 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 already declare readOnly, idempotent, non-destructive, open-world. The description adds real value beyond them: it states the ledger is not modified, that calls are subject to configured gateway rate limits, and that the result lists trust-line state with issued-asset balances and limits. It stops short of describing error behavior or response shape, but this is well above the 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-loads the purpose, then parameter roles, then return/behavioral notes, then sibling routing. Dense but every clause earns its place with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description compensates by describing what the result contains (trust-line state, issued-asset balances and limits). With read-only safety covered by annotations, an agent has everything needed 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%, so the baseline is 3, but the description adds meaning beyond the schema: peer 'restricts results to one counterparty', limit 'caps returned trust lines', marker 'continues pagination from a previous response', ledger_index 'pins the lookup to a validated ledger'. These are functional roles, not restatements.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only XRPL trust-line lookup for one account') and immediately names the two sibling tools it is not (get_account_info, list_account_objects). An agent can distinguish it from the other list_account_* siblings 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?

Explicitly routes: use this for trust lines and issued-asset holdings; use n9t2_xrpl_get_account_info for current account state or n9t2_xrpl_list_account_objects for other ledger objects. That is a clear when-to-use with named 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?

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real behavioral context: pagination via marker, ledger pinning via ledger_hash/ledger_index, and gateway rate-limit exposure. It stops short of return-format/pagination-shape detail, but that is a minor gap.

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?

Purpose is front-loaded in the first clause, followed by return fields, pagination/ledger controls, rate limits, and alternatives in a logical order. Dense but nearly every sentence carries distinct information; the enumeration of return fields is slightly long but justified by the absence of an output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by naming the returned NFT fields, and it covers pagination, ledger pinning, rate limits, and sibling disambiguation. Nothing an agent needs to invoke this read tool 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 coverage is 100%, so the baseline is 3, and the description earns above it by explaining how marker continues pagination and how ledger_hash/ledger_index pin the lookup to a specific ledger. It also enumerates returned NFT fields (NFTokenID, Issuer, NFTokenTaxon, URI, nft_serial), adding meaning the schema does not carry.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('read-only XRPL NFT inventory lookup for one classic account') and names the native method it wraps. It explicitly differentiates itself from n9t2_xrpl_list_nft_offers and n9t2_xrpl_list_account_objects, so an agent can route 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?

Provides explicit when-to-use ('NFTs owned by an account') plus two named alternatives with the conditions that select them (marketplace offers on a specific NFTokenID vs raw ledger objects). Nothing is left 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 already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully carried by structured data and the description's 'read-only' restates it. The description does add genuine context — 'canonical' (validated-ledger) scope and the catch-all role — plus pagination via limit/marker, but it says nothing about the shape of returned ledger entries or error behavior. With annotations doing the heavy lifting, a 3 is appropriate.

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 capability, then the routing rules, then parameter tips — a sensible order with no filler. Five dense sentences is on the long side, but each carries distinct information (scope, catch-all role, four alternatives, object_type caveat, pagination).

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 7-parameter read tool with full annotation coverage and no output schema, the description covers what it is, when to prefer it, and how to page and pin the lookup. The only real gap is that the return shape of 'raw ledger-entry objects' is left implicit, which matters because there is no output schema to fall back on.

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 goes beyond the schema by explaining the intent behind a parameter choice: set object_type to 'nft_offer' only when raw NFTokenOffer ledger entries are required, and use ledger_index to pin the lookup. That routing rationale is not derivable from the schema text alone.

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 and access mode ('Read-only XRPL canonical ledger-object lookup for one account') and immediately names the four sibling views it supersedes. An agent can distinguish this catch-all from n9t2_xrpl_list_account_nfts, n9t2_xrpl_list_nft_offers, n9t2_xrpl_list_account_offers and n9t2_xrpl_list_account_channels 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?

Gives an explicit selection rule: use this 'low-level catch-all when raw ledger-entry objects are required or when no dedicated N9T2 view exists', then enumerates each alternative and the condition that routes to it (NFTs, marketplace offers on a specific NFTokenID, classic DEX offers, Payment Channels). Both when-to-use 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond them: gateway rate limits apply, and the operation never mutates offers. It stops short of describing response shape, though the safety-relevant behavior is well disclosed.

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 and the sibling differentiation, then packs parameter guidance and the non-mutating guarantee into a few sentences. Slightly dense but every clause carries information; no padding.

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 still tells the agent what comes back (outstanding offers) and how to paginate via marker. For a 5-param read tool with full schema coverage and rich annotations, this is complete enough, though return-shape detail is absent.

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, but the description adds operational meaning: marker is for continuing pagination, ledger_index pins the lookup to a validated ledger, and strict forces exact interpretation of the account identifier. This goes beyond the terse schema 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?

States a specific verb and resource ('account-offer lookup for one account') with explicit scope: returns that account's outstanding offers rather than global order-book depth. It names the sibling it is not, so an agent can distinguish it from n9t2_xrpl_get_book_offers without opening a 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?

Explicitly names the alternative ('use n9t2_xrpl_get_book_offers for global market depth') and the condition that selects this tool (the account's own open offers). It also states when-not by clarifying it does not create, cancel, or modify offers.

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, non-destructive and open-world, so the bar is lower, yet the description still adds real context: it clarifies the call does not modify the ledger or submit transactions, and discloses that calls are subject to configured gateway rate limits and that a pagination marker signals remaining history. That is meaningful operational disclosure beyond the 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?

Three front-loaded sentences: purpose and sibling routing first, then parameter roles, then safety/pagination/rate-limit notes. Efficient and well ordered, with only mild restatement of schema-documented parameter meanings.

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 compensates by describing the result ('account transaction records') and pagination behavior. Combined with the safety and rate-limit notes, an agent has enough to invoke and interpret this correctly; only richer return-shape detail is absent.

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 all four parameters are already documented. The description restates the roles of ledger_index_min/max (history window) and limit (bounds records) but adds no syntax, format, or default behavior beyond the schema — baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Read-only XRPL transaction-history lookup for one account') with scope modifiers, and explicitly distinguishes itself from the closest sibling, n9t2_xrpl_get_transaction. An agent can route between history lookup and single-transaction lookup without inspecting 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?

Gives an explicit when-to-use ('multiple account transactions') and names the alternative tool plus the condition that selects it ('when a transaction hash is already known'). This is exactly the routing guidance an agent needs among 18 siblings.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: offer_type maps to distinct native structures (nft_buy_offers vs nft_sell_offers), and buy_marker/sell_marker paginate the two sides independently, which is non-obvious. It stops short of describing return shape, so not 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 core purpose and the offer_type branching are front-loaded, and the sibling routing comes last where it belongs. It is dense and slightly long, but each sentence carries distinct 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 should carry the full burden, and it covers lookup scope, side selection, pagination, and ledger pinning. It omits return-value shape and marker semantics for continuing pagination, which are minor gaps for a read-only listing 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 baseline is 3, but the description adds meaning the schema does not: it explains that buy/sell markers paginate independently, that ledger_hash/ledger_index pin the lookup to a ledger, and that limit bounds returned offers. This is genuine semantic value on top of the structured 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 states a specific verb and resource ('Read-only XRPL NFT marketplace-offer lookup for one NFTokenID') and immediately scopes it to a single NFT. It explicitly distinguishes itself from n9t2_xrpl_list_account_nfts and n9t2_xrpl_list_account_objects, so an agent can separate it from siblings 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?

It gives explicit when-to-use routing: use this for marketplace offers on a specific NFT, use list_account_nfts for owned inventory, and use list_account_objects with object_type='nft_offer' when raw ledger entries are needed. Both alternatives and the selecting condition are named.

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, destructiveHint=false), and the description adds behavior beyond them: unsupported types and invalid builder parameters are rejected before a result is returned, sequence/fee/last_ledger_sequence may be autofilled when omitted, and no private keys or seeds are ever received or stored. That is meaningful operational and security context for a construction tool.

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?

Five sentences, front-loaded with the purpose before the validation, autofill, and handoff details. Slightly repetitive around the 'unsupported types / invalid parameters' rejection clause, but no sentence 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?

No output schema exists, so the description correctly characterizes the return value as unsigned transaction JSON for local signing. It covers validation, autofill, and key-handling, though for a tool with ~79 enum transaction types it cannot describe per-type field requirements, leaving some construction detail to the caller.

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 enum plus nested object are documented, so the baseline is 3. The description adds value by explaining the polymorphic contract: pick exactly one transaction_type and supply that model's fields inside the otherwise free-form (additionalProperties=true) parameters object, with examples of supported types. It still does not indicate which fields a given type requires.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Prepare one unsigned XRPL transaction') plus the intended consumer ('for agent-local signing'). It also implicitly distinguishes itself from n9t2_xrpl_submit_transaction by framing itself as the construction primitive, so an agent can tell the two apart 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?

Gives clear when-to-use context ('generic transaction-construction primitive for supported XRPL transaction types') and an explicit downstream handoff ('after signing, pass the signed tx_blob to n9t2_xrpl_submit_transaction'). It does not state any when-not conditions or prerequisites, so it stops short of full 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?

Annotations already declare destructiveHint=true and openWorldHint=true, but the description adds real context: it mutates ledger state only when accepted, submission is tentative, secrets must never be passed, and invalid/rejected blobs error. It does not cover rate limits or whether retries are safe for the caller, which keeps it short of 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?

Dense but front-loaded, opening with the core action before prerequisites, safety, parameter notes, and confirmation flow. Every sentence carries information, though the result-field enumeration is somewhat long for prose that an output schema also covers.

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 destructive, open-world submission tool it covers prerequisites (local signing), the mutation semantics, safety constraints, parameter behavior, tentative-result caveats, error behavior, and the follow-up verification step. Nothing an agent needs to call 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 coverage is 100%, so the baseline is 3; the description goes beyond it by explaining what tx_blob must be (complete signed transaction in hex, produced by local signing) and by expanding fail_hard's effect (no local retry or relay). The tx_blob wording largely mirrors the schema, so it is not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Submit one already-signed XRPL transaction') and pins the scope to already-signed blobs, distinguishing it from prepare_transaction (signing pipeline) and get_transaction (confirmation). An agent can select it without opening the 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?

Explicitly routes the agent: obtain the blob from the local signing step 'normally after n9t2_xrpl_prepare_transaction', and confirm inclusion with n9t2_xrpl_get_transaction using the returned hash. Names both the predecessor and successor tools and the condition for each.

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, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so safety is largely covered. The description adds real lifecycle context beyond that: it sends the subscribe command, collects until duration_seconds expires or max_events is reached, then closes the connection and returns the ack plus events, and it restates the read-only constraint. It stops short of auth requirements or rate-limit detail, so not 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?

Front-loaded with purpose and the when-to-use rule, then lifecycle, then defaults, then caveats. It is a touch long at five sentences, but each sentence carries distinct information (purpose, routing, mechanics, defaults, exclusion) with no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so ('returns the subscription acknowledgement plus captured events'). Combined with the bounding mechanics, defaults, and read-only note, an agent has everything needed to invoke it correctly without opening the schema.

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 the schema does not: when subscription inputs are omitted the effective default is the ledger stream for 3 seconds with up to 25 events. The schema only shows per-field defaults (streams default null), so the description usefully resolves the composite default.

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 (open a subscription) and resource (bounded native XRPL WebSocket subscription) with explicit scope: streams, accounts, proposed transactions, or order books. It is unmistakably distinguished from the sibling one-time snapshot tools (get_*/list_*) by naming the streaming behavior directly in the second sentence.

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 an explicit selection rule: 'Use this when an agent needs event-driven updates instead of a one-time snapshot,' which routes the agent against every sibling tool. It also provides a negative/exclusion guideline ('Do not request the admin-only peer_status stream unless the upstream XRPL server permits it') and clarifies the default behavior when inputs are omitted.

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