Read-only XRPL and Solana data for agents: fees, slippage, readiness. Free /mcp; x402 /mcp/pro.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 16 tools
Each tool targets a distinct resource or check, with clear cross-references in descriptions to disambiguate similar endpoints (e.g., account_summary vs account_lines, amm vs orderbook). The only minor overlap is between Solana's network_health and latest_slot, but their purposes are explicitly differentiated.
All tools use lower_snake_case with a network prefix (solana_ or xrpl_), and the naming pattern is predictable across both chains. No mixing of conventions.
16 tools is slightly above the typical 3-15 range, but reasonable given the server spans two separate blockchain networks (Solana and XRPL) with distinct resource types. Each tool maps to a specific endpoint or check.
XRPL coverage is strong, covering account, token, AMM, CLOB, fee, paths, and readiness checks. Solana coverage is thinner (only slot, network health, token safety, transfer readiness), missing account balance and transaction history, but core safety workflows are present.
Latest finalized Solana slot and its block time. When to use: To check how fresh the finalized view of Solana is, or to anchor a read to a slot. Prefer another tool: Not a tip-of-chain feed: it is finalized, not processed or confirmed, and it is cached for 2 seconds. Example: solana_latest_slot {}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| slot | Yes | Latest finalized slot |
| block_time | Yes | Block time of that slot; null when unavailable |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent and openWorld, so the safety profile is free. The description adds genuinely new behavioral context: the 2-second cache and the finalized-vs-processed/confirmed distinction, both of which affect how an agent interprets freshness. It does not cover error or failure 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-loaded with the return contract, then usage, then caveat, then example, with no wasted prose. The 'Prefer another tool:' label is slightly confusing since no tool is actually named after it.
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?
An output schema exists, so return values need not be explained, and for a no-arg read the description is nearly sufficient. The one missing piece is the identity of the alternative tool the caveat alludes to, which the sibling list suggests exists.
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 there is no parameter semantics to convey and the schema imposes no burden; baseline 4 applies. The description correctly shows the empty-argument call form via the example.
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 the specific resource and scope: the latest FINALIZED slot plus its block time. That scope word distinguishes it from a tip-of-chain feed, but no sibling (e.g., get_latest_ledger, solana_network_health) is named, so the agent must still infer which Solana freshness tool to pick.
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 a concrete when-to-use condition (check how fresh the finalized view is, or anchor a read to a slot) and a when-not (not a tip-of-chain feed, finalized rather than processed/confirmed). It stops short of naming the specific alternative tool the 'Prefer another tool' line gestures at.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether Solana data is currently being served: latest probe status and finalized slot. When to use: Before relying on the Solana verdict endpoints, or to explain a 503 from them. Prefer another tool: Not a measure of the Solana network itself, only of this service's access to it; use the latest-slot endpoint to see chain progress. Example: solana_network_health {}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| slot | Yes | Finalized slot of the latest successful probe |
| status | Yes | Latest probe result; `unavailable` while Solana data is not configured |
| latency_ms | Yes | |
| last_probe_at | Yes |
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 genuine semantic context beyond that: the tool reflects this service's access to Solana rather than the network itself, and it is the diagnostic for 503 responses from the verdict endpoints. It stops short of describing refresh cadence or staleness of the probe.
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 definition, then clearly labeled sections for usage and the closest alternative, plus a call example. Efficient overall, though the label 'Prefer another tool:' is slightly misapplied to what is actually a scope clarification rather than a sibling recommendation.
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?
A zero-parameter, read-only diagnostic with an output schema describing probe status and finalized slot, plus rich annotations. The description covers what it reports, why it exists, when to reach for it, and what it must not be confused with — 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 the baseline of 4 applies. The description supplies a concrete empty-object invocation example ('solana_network_health {}'), which is a small but real aid for calling it correctly.
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 ('Whether Solana data is currently being served: latest probe status and finalized slot') and explicitly scopes it away from the chain itself. It also distinguishes itself from the sibling solana_latest_slot by naming that endpoint as the place to see chain progress.
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 ('Before relying on the Solana verdict endpoints, or to explain a 503 from them') and an explicit when-not, pointing at the latest-slot endpoint for chain progress. This is textbook routing guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is this Solana token safe to hold or receive? A SAFE, WARN or DANGER verdict. When to use: Before accepting or swapping into an unfamiliar token, to see whether its mint can freeze, mint more, move or tax balances. Prefer another tool: Not a price, liquidity or holder lookup and not an audit of the token's project; it reads only the mint account. Example: solana_token {"mint":"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | Mint address of an SPL Token or Token-2022 token (base58, 32 bytes) |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| mint | Yes | |
| supply | Yes | Total supply in raw units, exact |
| reasons | Yes | Every matched code of every level; empty for SAFE |
| verdict | Yes | Highest level matched: DANGER > WARN > SAFE |
| decimals | Yes | |
| extensions | Yes | Token-2022 mint extensions by name; empty for SPL Token |
| transfer_fee | Yes | Transfer fee active at the current epoch; null without a fee config |
| token_program | Yes | SPL Token or Token-2022 program address |
| mint_authority | Yes | Null when the mint authority is renounced |
| freeze_authority | Yes | Null when the freeze authority is renounced |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, openWorld, and non-destructive, so the bar is lower; the description still adds the important scope limit 'it reads only the mint account', telling the agent the verdict is derived from on-chain mint authority flags rather than off-chain analysis. It stops short of stating rate limits, auth requirements, or how long a verdict stays fresh.
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 question and verdict vocabulary, then ordered when-to-use, exclusions, and a concrete example. Every clause carries information; nothing is boilerplate 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?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. Combined with the stated checks (freeze/mint/tax authority), the scope limit (mint account only), the trigger conditions, and a worked example, an agent has everything needed to select and call 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?
With one parameter at 100% schema description coverage, the schema already documents the base58 32-byte mint address, so baseline is 3. The inline example (a USDC mint) usefully confirms the expected value format in context, but adds no semantics beyond the schema's own field 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 question it answers ('Is this Solana token safe to hold or receive?') and the exact output form ('A SAFE, WARN or DANGER verdict'). It also names what it is not ('Not a price, liquidity or holder lookup'), which separates it from siblings like get_token, estimate_slippage, and get_account_lines without opening their 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?
'When to use: Before accepting or swapping into an unfamiliar token' gives an explicit trigger, and 'Prefer another tool' explicitly excludes price/liquidity/holder lookups and project audits. It even lists the concrete risk questions answered (freeze, mint more, move or tax balances), so the agent can match it to intent precisely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Will this Solana transfer succeed? A verdict for SOL or an SPL or Token-2022 token. When to use: Before building or signing a Solana transfer, to learn whether it will fail and what it will cost in rent and fees. Prefer another tool: Not a simulation of the exact transaction (no priority fee, no program logic), not a token price or holder lookup, and not a way to read raw accounts. Example: solana_transfer_readiness {"source":"83astBRguLMdt2h5U1Tpdq5tjFoJ6noeGwaY3mDLVcri","destination":"A1TMhSGzQxMr1TboBKtgixKz1sS6REASMxPo1qsyTSJd","mint":"SOL","amount":"0.5"}
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | `SOL` for native SOL, or the mint address of an SPL Token or Token-2022 token | |
| amount | Yes | Positive decimal amount in UI units (SOL or tokens, not lamports or raw units) | |
| source | Yes | Sending wallet: Solana wallet address: a base58 string that decodes to exactly 32 bytes | |
| destination | Yes | Receiving wallet (not its token account): Solana wallet address: a base58 string that decodes to exactly 32 bytes |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| mint | Yes | `SOL` or the mint address |
| ready | Yes | True when no blocker applies |
| amount | Yes | Amount checked, in the asset's UI units (as sent) |
| source | Yes | Sending wallet address |
| blockers | Yes | Every blocking code that matched |
| decimals | Yes | Decimals of the asset (9 for SOL) |
| warnings | Yes | Every non-blocking warning that matched |
| amount_raw | Yes | Amount in raw units (lamports for SOL) |
| net_amount | Yes | Raw units the destination receives after any transfer fee |
| destination | Yes | Receiving wallet address |
| transfer_fee | Yes | Token-2022 transfer fee in raw units; null without a fee config |
| token_program | Yes | Token program that owns the mint; null for SOL |
| ata_creation_lamports | Yes | Rent-exempt lamports to create the destination token account; null when not needed |
| requires_ata_creation | Yes | True when the destination has no associated token account yet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world, so safety is covered. The description adds genuinely new behavioral information: the result is a heuristic verdict rather than an exact simulation ('no priority fee, no program logic') and it reports rent and fee costs, which tells the agent the limits of what it may conclude. It doesn't state data freshness against the live chain, which the openWorldHint implies.
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 question and then cleanly segmented into usage, exclusions, and an example, with no filler sentences. The inline example with three full base58 addresses is bulky and consumes disproportionate space, which 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 an output schema present, return values needn't be documented, and the description still characterises the output (verdict plus rent and fee cost) and the boundaries of the check. Nothing needed to invoke the tool correctly is missing; only chain-freshness/latency context 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. The embedded example call adds modest value by demonstrating that mint takes the literal string "SOL" and that amount is a UI-unit decimal string, showing the four parameters working together. It adds no semantics the schema lacks, so it stays at 4 rather than 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?
The opening question 'Will this Solana transfer succeed?' plus 'A verdict for SOL or an SPL or Token-2022 token' gives a specific verb (readiness verdict), resource (Solana transfer), and scope (token standards) that no sibling in the list covers. An agent can distinguish this from check_payment_readiness or estimate_slippage 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 'When to use' clause ('Before building or signing a Solana transfer') gives a clear trigger condition, and the 'Prefer another tool' block explicitly excludes simulation, price/holder lookup, and raw account reads. It falls short of 5 because it never names the closest actual sibling (check_payment_readiness), so the agent must infer the boundary between the two readiness tools itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One page of an account's trust lines, with an opaque cursor for the next page. When to use: To list every trust line of an account (balances, limits, freeze and authorization flags), page by page. Prefer another tool: For a quick capped overview with the XRP balance, use /v1/xrpl/account/{address}/summary; for issued totals of a token, use the token endpoint. Example: xrpl_account_lines {"address":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| peer | No | Only lines with this counterparty (classic address) | |
| limit | No | Lines per page: an integer from 10 to 400 (default 100) | |
| marker | No | Opaque cursor from the previous page's `marker`, for the same address | |
| address | Yes | Valid classic XRPL account address (r..., checksum verified) |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| peer | Yes | |
| limit | Yes | |
| lines | Yes | |
| marker | Yes | Opaque cursor for the next page (send as `marker`); null on the last page |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnlyHint, destructiveHint false, idempotent, openWorld), and the description adds behavioral context beyond them: it's paginated, returns an 'opaque cursor for the next page', and lists what fields are returned. It doesn't discuss rate limits or failure modes, but for a read-only listing tool with full annotation coverage, this is solid.
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 structured with clear 'When to use' and 'Prefer another tool' cues, ending with an example. Reasonably tight, though the parenthetical field list and example slightly lengthen it beyond the minimum needed.
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 paginated read-only list tool with 4 params, full schema coverage, an output schema, and full annotations, the description covers purpose, alternatives, pagination behavior, and an example. 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 description coverage is 100%, so the schema already fully documents each parameter (peer, limit, marker, address). The description provides an example invocation with address but adds no additional parameter syntax or semantics beyond what the schema states. 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+resource+scope: 'One page of an account's trust lines, with an opaque cursor for the next page.' It also names what trust lines contain (balances, limits, freeze and authorization flags) and distinguishes from siblings by explicitly naming the alternatives (summary endpoint, token endpoint).
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' and 'Prefer another tool' sections name the alternative tools and the conditions for choosing them: '/v1/xrpl/account/{address}/summary' for a quick capped overview, token endpoint for issued totals. 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.
XRP balance, sequence, owner count, transfer rate and trust lines (capped) for an account. When to use: To inspect an account before building a transaction for it. Prefer another tool: Not for transaction history, reserves or account flags; it is a summary, not a full account dump. Example: xrpl_account_summary {"address":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Valid classic XRPL account address (r..., checksum verified) |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| address | Yes | |
| sequence | Yes | |
| balance_xrp | Yes | Decimal string |
| owner_count | Yes | |
| trust_lines | Yes | |
| transfer_rate | Yes | Issuer TransferRate, 1000000000 = no fee |
| lines_truncated | Yes |
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 a genuinely non-obvious behavioral trait beyond that: trust lines are returned 'capped', warning the agent that the result set may be truncated. It stops short of saying what the cap is or whether further pagination exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the return payload, then usage, exclusions and an example — a sensible ordering with no filler sentences. The field list is dense but every item is informative; the labeled structure ('When to use:', 'Prefer another tool:') is slightly formulaic but earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description need not explain return values. Combined with annotations covering the safety profile and the description covering scope, the 'capped trust lines' caveat, and exclusions, an agent has everything needed to select and 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?
Only one parameter and schema description coverage is 100%, so the schema already documents the address format including checksum verification. The description's example call reinforces the shape but adds no semantic meaning (no hint about encoded addresses, tags, or malformed-input behavior) beyond what the schema states. 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?
Names the exact resource (an XRPL account) and enumerates the returned fields (XRP balance, sequence, owner count, transfer rate, trust lines), which is far more specific than the title 'Account summary'. The sibling landscape includes xrpl_account_lines and xrpl_account_transactions, and the description explicitly excludes both, so an agent can disambiguate 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?
Provides an explicit when-to-use ('inspect an account before building a transaction for it') and an explicit when-not ('Not for transaction history, reserves or account flags'), naming the sibling domains it overlaps with. The pre-transaction framing also implies the correct ordering relative to xrpl_payment_readiness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One page of an account's most recent validated transactions, newest first. When to use: To check what an account did recently (payments sent or received, offers, trust line changes) and whether each transaction succeeded. Prefer another tool: For balances and trust lines, use /v1/xrpl/account/{address}/summary or /v1/xrpl/account/{address}/lines; for full archival history, use a full-history node or indexer: history depth depends on the serving node and older pages may be slower. Example: xrpl_account_transactions {"address":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Transactions per page: an integer from 1 to 50 (default 20) | |
| marker | No | Opaque cursor from the previous page's `marker`, for the same address | |
| address | Yes | Valid classic XRPL account address (r..., checksum verified) |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| limit | Yes | |
| marker | Yes | Opaque cursor for the next (older) page (send as `marker`); null on the last page |
| address | Yes | |
| transactions | Yes | Validated transactions, newest first |
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 adds genuine behavioral context beyond them: history depth depends on the serving node and older pages may be slower, which matters for an agent deciding whether to paginate deeply.
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 purpose, then routes usage with labeled clauses, and closes with an example. Mostly tight, though the archival-history caveat is squeezed into the 'Prefer another tool' sentence rather than standing on its own.
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 an output schema present (return values need not be explained) and annotations covering safety, the description supplies the missing pieces: when to use it, when to use something else, and node-dependent history depth. Nothing needed to call it correctly 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% – address, limit (1-50, default 20) and marker are all documented in the schema. The description only adds a concrete example invocation, which illustrates but does not extend parameter semantics. 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 ('One page of an account's most recent validated transactions, newest first') including scope (one page, validated, newest first). This clearly separates it from siblings like xrpl_account_summary and xrpl_account_lines.
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' clause enumerates the scenarios (payments, offers, trust line changes, success status), then a 'Prefer another tool' clause names the exact alternatives (/summary, /lines) and conditions that select them, plus guidance for archival history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AMM pool reserves and trading fee for an asset pair. When to use: To read AMM pool depth and fee for a pair. Prefer another tool: It does not estimate slippage or compare venues (use the slippage page for the CLOB vs AMM comparison); a pair without a pool returns 404. Example: xrpl_amm {"a":"XRP","b":"USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | First asset: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) | |
| b | Yes | Second asset: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| asset_a | Yes | |
| asset_b | Yes | |
| reserve_a | Yes | Decimal string |
| reserve_b | Yes | Decimal string |
| trading_fee | Yes | Decimal string |
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 structurally. The description adds value beyond that by disclosing the 404-on-missing-pool behavior and by bounding scope (no slippage estimation), though it says nothing about response shape or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with what it returns, then compact labeled fragments for usage, exclusions and an example. Dense and mostly waste-free, though the 'Prefer another tool:' label reads slightly awkwardly against the following clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only tool with full schema coverage, an output schema and complete annotations, the description covers purpose, selection criteria and the failure case. Nothing essential is missing, though it could note whether non-XRPL DEX AMMs are covered.
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 document the XRP vs CODE.issuer format fully. The worked example mirrors that format without adding new syntax rules, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource (AMM pool reserves and trading fee) scoped to an asset pair, so the agent knows exactly what comes back. It is clearly separable from siblings like xrpl_orderbook and xrpl_slippage, which the description itself invokes by name.
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 labeled 'When to use' plus an exclusion clause stating it does not estimate slippage or compare venues, and routes that need to the slippage page / xrpl_slippage. Also documents the no-pool 404 case, which is the main edge condition for calling this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current XRPL fee tiers in drops with a congestion score. When to use: Before submitting a transaction, to choose a Fee and to decide whether the network is congested. Prefer another tool: Not a price feed and not a historical series; it describes the latest validated ledger only. Example: xrpl_fee {}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| fee | Yes | |
| meta | Yes | |
| base_fee | Yes | Decimal string |
| congestion | Yes | |
| median_fee | Yes | Decimal string |
| minimum_fee | Yes | Decimal string |
| max_queue_size | Yes | Decimal string |
| open_ledger_fee | Yes | Decimal string |
| current_queue_size | Yes | Decimal string |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description adds incremental value: it discloses data freshness ('latest validated ledger only') and that it is not historical or price-oriented. It does not discuss caching, rate limits, or what the congestion score means, so it is useful 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?
Three short, labelled sentences plus an example, with the payload description front-loaded and no filler. Every clause earns its place by either stating scope or excluding a wrong interpretation.
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 an output schema present, return-value detail is not required, and the description covers purpose, timing, freshness, and exclusions for a zero-param read. The only minor gap is that the semantics of the 'congestion score' scale are left entirely to the 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?
The tool takes zero parameters, so the baseline is 4. The description appropriately spends no space on parameters and instead includes a call example ('xrpl_fee {}'), which is the only parameter-relevant information possible here.
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 opening sentence names the resource (XRPL fee tiers), the unit (drops), and an extra returned signal (congestion score) in one line. It further distinguishes itself from siblings by stating it is 'not a price feed and not a historical series' and covers 'the latest validated ledger only'.
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 trigger ('before submitting a transaction, to choose a Fee and to decide whether the network is congested') and an explicit negative scope ('Prefer another tool: Not a price feed and not a historical series'). This routes an agent without requiring it to open any other schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest validated ledger index, hash and close time. When to use: To anchor other readings to a ledger or to check how current the network view is. Prefer another tool: Not for transaction data or account state; use the account endpoint for those. Example: xrpl_latest_ledger {}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| close_time | Yes | |
| ledger_hash | Yes | |
| ledger_index | Yes |
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 adds the meaningful 'validated' qualifier (only validated ledgers, not open ones) and freshness semantics, but the enumerated return fields largely duplicate the output schema.
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 return content, then when-to-use, then the exclusion, then a concrete example. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema covering the return shape, and annotations carrying the safety profile, the description supplies everything an agent needs to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. The example call with an empty argument object usefully confirms that no input is expected.
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 specific verb+resource ('Latest validated ledger index, hash and close time') and explicitly distinguishes itself from siblings by ruling out transaction data and account state. An agent can identify this tool 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 ('anchor other readings to a ledger or check how current the network view is') and an explicit when-not clause pointing to the account endpoint for transaction/account data. Routing guidance is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overall and per-node health of the upstream XRPL nodes. When to use: To decide whether to trust or retry data, or to explain a 503 from another endpoint. Prefer another tool: Not a probe of your own connectivity; it reports the service's upstream nodes. Example: xrpl_network_health {}
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| nodes | Yes | |
| status | Yes | |
| ledger_index | Yes | |
| last_probe_at | Yes |
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 adds genuine behavioral context beyond them: it reports the service's upstream nodes rather than caller connectivity, and it can be used to diagnose a 503 from other endpoints. Return-shape detail is deferred to the existing output schema, which is acceptable.
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 labeled sentences plus a call example; the purpose is stated before the usage and anti-use guidance. Every sentence carries information an agent needs, 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 parameters, rich annotations, and an existing output schema to carry the return shape, the description only needs to explain purpose and selection rationale, which it does fully. Nothing needed 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?
The tool takes zero parameters, so the baseline is 4. The description reinforces this by showing the call as 'xrpl_network_health {}', leaving no ambiguity that no arguments are required.
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 gives a specific resource and scope: overall and per-node health of the upstream XRPL nodes. It distinguishes itself from sibling health tools by specifying 'upstream XRPL nodes' and by explicitly denying that it probes the caller's own connectivity. An agent can tell this apart from solana_network_health and the xrpl_* data tools 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?
It states explicit when-to-use conditions ('to decide whether to trust or retry data, or to explain a 503 from another endpoint') and an explicit anti-use case ('Not a probe of your own connectivity'). This is the when/when-not pattern the rubric rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
CLOB order book for a currency pair with unfunded offers removed. When to use: To read executable liquidity for a pair on the XRPL central limit order book (CLOB). Prefer another tool: Not for AMM liquidity (use the amm page) and not for a cost estimate (use the slippage page). Example: xrpl_orderbook {"base":"XRP","quote":"USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base currency: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) | |
| depth | No | Levels per side: a positive integer, rounded up to 10, 50, 100 or 200 (max 200) | |
| quote | Yes | Quote currency: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) |
| Name | Required | Description |
|---|---|---|
| asks | Yes | Best (lowest) price first |
| base | Yes | |
| bids | Yes | Best (highest) price first, from the base-asset side |
| meta | Yes | |
| depth | Yes | |
| quote | Yes |
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 by structured data. The description adds real behavioral context beyond that: results are filtered to executable liquidity because unfunded offers are removed, which changes how the output must be interpreted. It stops short of describing pagination or empty-side behavior, 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 the core definition, then clearly delimited 'When to use', 'Prefer another tool' and 'Example' sections. The embedded example largely duplicates the schema's own example, a minor redundancy in an otherwise tight definition.
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 pair lookup with an output schema and 100% parameter coverage, what the tool does, when to use it and which siblings to prefer are all present. Remaining details (defaults for depth, behavior when one side is empty) are adequately handled by the schema/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 description coverage is 100%, so base, quote and depth are already fully documented, including the depth rounding rule, in the schema itself. The description's example repeats the base/quote format already shown in the schema and adds no new meaning. 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+resource ('CLOB order book for a currency pair') and a distinguishing qualifier ('with unfunded offers removed'). An agent can separate this from xrpl_amm and xrpl_slippage 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' line plus two named exclusions routing to sibling tools (AMM liquidity -> amm page, cost estimate -> slippage page). The condition that selects each alternative is stated, not implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-hop payment paths and their source cost. When to use: Before a cross-currency or multi-hop payment: to see whether a route exists and how much the source would spend to deliver the amount. A call can take up to about 20 seconds and paths may be non-optimal. Prefer another tool: To check whether a direct payment can succeed (use /v1/xrpl/payment-readiness), or for the single-hop cost of a trade on one pair (use /v1/xrpl/slippage, which compares the order book and the AMM). Example: xrpl_paths {"source":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh","destination":"rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B","asset":"XRP","amount":"1"}
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Asset delivered: XRP or CODE.issuer (3-character or 40-hex code, classic issuer) | |
| amount | Yes | Positive decimal amount of asset the destination receives | |
| source | Yes | Sending account: valid classic XRPL address (r..., checksum verified) | |
| send_max | No | Most the source may spend, in send_max_asset; not with source_assets | |
| destination | Yes | Receiving account: valid classic XRPL address | |
| source_assets | No | Comma-separated assets the source may spend (1 to 4); not with send_max | |
| send_max_asset | No | Asset of send_max: XRP or CODE.issuer; give it with send_max |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| warnings | Yes | Non-blocking warnings |
| alternatives | Yes | Path alternatives; empty when none was found |
| paths_may_be_non_optimal | Yes | Path finding is best effort: a cheaper path may exist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so safety is covered; the description adds genuinely new behavior that annotations cannot express: a ~20-second worst-case latency and that returned paths may be non-optimal. It stops short of describing truncation, error modes, or how 'source cost' is reported, 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 one-line purpose followed by clearly labelled 'When to use', 'Prefer another tool', and 'Example' sections. Long but every sentence carries distinct routing or behavior 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?
Output schema exists, so return structure needn't be explained. Purpose, routing, latency caveat, and a concrete invocation example cover everything an agent needs to call this 7-parameter tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and already documents every field, including the send_max/source_assets mutual exclusion and asset formats. The description adds no syntax beyond the example call, 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 resource ('Multi-hop payment paths') plus the core output ('their source cost'), which is exactly what distinguishes it from the single-hop siblings. An agent can tell what it produces 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?
Explicit 'When to use' (before a cross-currency or multi-hop payment, to test route existence and cost) and explicit routing away to named alternatives: payment-readiness for direct payments, slippage for single-pair trade cost. Nothing left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pre-payment check: can this payment from source to destination succeed now? When to use: Right before sending a payment: to catch a missing or unfunded destination, a required destination tag, deposit authorization, missing or frozen trust lines, insufficient balance and issuer freezes, in one call. Prefer another tool: To find a multi-hop route or the source amount needed for a cross-currency payment (use the paths endpoint), or to list balances (use /v1/xrpl/account/{address}/summary). Example: xrpl_payment_readiness {"source":"rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh","destination":"rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B"}
| Name | Required | Description | Default |
|---|---|---|---|
| asset | No | XRP (default) or CODE.issuer (3-character or 40-hex code, classic issuer) | |
| amount | No | Positive decimal amount of asset; omit to skip amount-dependent checks | |
| source | Yes | Sending account: valid classic XRPL address (r..., checksum verified) | |
| destination | Yes | Receiving account: valid classic XRPL address, different from source | |
| destination_tag | No | Destination tag you will send: an integer from 0 to 4294967295 |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| asset | Yes | `XRP` or `CODE.issuer` |
| amount | Yes | Amount checked; null when omitted (amount checks skipped) |
| source | Yes | |
| reasons | Yes | Blocking reason codes |
| verdict | Yes | `not_ready` on any blocking reason; else `unknown` on any failed sub-check |
| warnings | Yes | Non-blocking warnings |
| destination | Yes | |
| checks_failed | Yes | Sub-checks that could not run |
| spendable_xrp | Yes | Source XRP above its live reserve and the standard fee; null when not computable |
| destination_tag | Yes | |
| transfer_fee_pct | Yes | Issuer transfer fee in percent, when it applies |
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 goes beyond that by enumerating the checks performed (unfunded destination, required destination tag, deposit authorization, frozen trust lines, insufficient balance, issuer freezes), which tells the agent what a failure means. It does not disclose latency or rate-limit behavior, so a 4 rather than 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-loads the purpose in the first clause, then uses labeled sections ('When to use', 'Prefer another tool', 'Example') so an agent can scan quickly. It is a dense single block and slightly long, but every clause carries routing or check-list 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 an output schema present, the description need not explain return values, and it already covers purpose, timing, the enumerated preconditions, and sibling alternatives. For a 5-parameter read-only check tool this is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters, including asset format and the omit-amount behavior. The description adds only an example invocation that exercises source and destination but says nothing about asset, amount, or destination_tag, so it does not meaningfully exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (pre-payment check) and resource (payment from source to destination) with scope (whether it can succeed now). It is clearly distinguishable from siblings like xrpl_paths and xrpl_account_summary, which the description explicitly names as the alternatives for other jobs.
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 timing ('Right before sending a payment'), the conditions to detect, and explicit 'prefer another tool' routing with two named alternatives (paths endpoint for routing/cross-currency, account summary for balances). 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.
Slippage and average price for buying an amount of base currency. When to use: Before placing a market-style trade, to size it against available depth and to see whether the CLOB or the AMM pool is the cheaper venue. Prefer another tool: It is an estimate, not a quote, and it does not split an amount across venues or route through other pairs. To read pool reserves, use the amm page. Example: xrpl_slippage {"base":"XRP","quote":"USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh","amount":"1000"}
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Base currency: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) | |
| depth | No | Levels per side: a positive integer, rounded up to 10, 50, 100 or 200 (max 200) | |
| quote | Yes | Quote currency: `XRP` (no issuer) or `CODE.issuer` with a valid classic-address issuer (e.g. `USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh`) | |
| amount | Yes | Positive decimal amount of base to buy |
| Name | Required | Description |
|---|---|---|
| base | Yes | |
| meta | Yes | |
| side | Yes | |
| depth | Yes | |
| quote | Yes | |
| amount | Yes | Decimal string |
| filled | Yes | Decimal string |
| venues | Yes | CLOB vs AMM comparison for the same amount; no routing split |
| partial | Yes | |
| avg_price | Yes | |
| best_price | Yes | |
| slippage_pct | Yes | Percent, null when liquidity is insufficient |
| transfer_fee | Yes | |
| avg_price_after_fees | Yes | |
| transfer_fee_applied | Yes | |
| insufficient_liquidity | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so safety is covered. The description adds genuine behavioral context beyond them: it is a price estimate rather than an executable quote, and it deliberately does not split amounts or route through other pairs. It omits auth/rate-limit details, but those are minor here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the purpose, then clearly delimited 'When to use', 'Prefer another tool', and 'Example' segments. Every sentence carries weight, though the block is on the longer side for a four-parameter read 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 an output schema present, return values need no explanation, and annotations cover the safety profile. The description supplies the venue-comparison intent, the non-routing caveat, an alternative tool, and a concrete call example, leaving nothing essential for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so base/quote/amount/depth are fully documented in the schema, establishing the baseline of 3. The description's example illustrates base/quote/amount usage but adds no format or semantic detail beyond the schema, and the depth parameter goes unmentioned.
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 (estimate) and resource (slippage and average price for buying an amount of base currency) with the exact scope. An agent can distinguish it from xrpl_orderbook, xrpl_amm, and xrpl_paths 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 says when to use (before a market-style trade, to compare CLOB vs AMM depth) and when not (it is an estimate, not a quote; does not split or route across venues), and names a concrete alternative ('use the amm page'). This is exactly the routing guidance an agent needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Issuer data for an issued asset: flags, domain, transfer fee and total issued. When to use: Before accepting or sending an issued token: check that the issuer exists, is not frozen, whether holders need authorization, and the transfer fee charged on every transfer between non-issuer accounts. Prefer another tool: For XRP (not an issued asset; 400), for one account's own balances use /v1/xrpl/account/{address}/lines, and for prices use /v1/xrpl/orderbook or /v1/xrpl/amm/{a}/{b}. Example: xrpl_token {"asset":"USD.rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh"}
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | Issued asset as CODE.issuer (3-character or 40-hex code, classic issuer address); not XRP |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| domain | Yes | Issuer domain decoded to text, when set |
| issuer | Yes | Issuer address |
| currency | Yes | Canonical currency code (3 characters or 40 hex) |
| no_freeze | Yes | |
| obligations | Yes | Total issued of this currency; null when `obligations_status` is `unavailable` |
| require_auth | Yes | |
| global_freeze | Yes | |
| transfer_rate | Yes | Issuer TransferRate, 1000000000 = no fee |
| currency_ascii | No | Readable text of a 40-hex currency code; null when not printable ASCII; absent for XRP and 3-character codes |
| default_ripple | Yes | |
| transfer_fee_pct | Yes | Transfer fee in percent |
| obligations_status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world semantics, so the description only needs to add context. It does: it discloses that XRP yields a 400, that transfer fees apply between non-issuer accounts, and what issuer attributes come back. Return shape is left to the output schema, so it stops 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 payload summary, then clearly labeled usage, alternatives, and example segments; no filler. It is slightly long for a one-parameter read tool, but every clause carries routing or error 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 an output schema covering returns, full annotation coverage, and 100% parameter documentation, the description supplies everything else an agent needs: when to call it, when not to, sibling alternatives, and the XRP error condition.
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 schema already defines the asset as CODE.issuer and excludes XRP. The description's inline example reinforces the format but adds no syntax or constraint beyond the schema, matching the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the resource (issuer data for an issued asset) and enumerates the specific payload fields (flags, domain, transfer fee, total issued), which is precise enough to separate it from xrpl_account_lines and xrpl_orderbook 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' section ties the tool to concrete decisions (verifying issuer existence, freeze state, authorization requirements, transfer fee) and 'Prefer another tool' names three alternatives with the conditions that select them, plus the XRP 400 case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
solana_latest_slotsolana_network_healthsolana_tokensolana_transfer_readinessxrpl_account_linesxrpl_account_summaryxrpl_account_transactionsxrpl_ammxrpl_feexrpl_latest_ledgerxrpl_network_healthxrpl_orderbookxrpl_pathsxrpl_payment_readinessxrpl_slippagexrpl_tokenXRPL token rug-checks, issuer reputation & AMM data for AI agents. Pay-per-call USDC via x402.
Pay-per-call DeFi and macro intel for AI agents. x402 USDC tools via streamable HTTP /api/mcp.
Pay-per-call Solana data for AI agents over x402: token, account, tx, trending. No signup, no key.
Agent MCP for DeFi: cross-chain LINQ fan-out, AMM quotes/swaps, bridge, AI. Solana+EVM. Free+x402.
Add one secure layer between your agents and this server.
