Kryptonian Labs XRPL APIs

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 adds genuinely non-obvious behavioral context: this is a read-only estimate that does not split amounts across venues or route through other pairs, which materially affects how results should be interpreted.

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 usage, then exclusion, then a concrete example — a sensible ordering. Slightly dense with the 'Prefer another tool' phrasing sitting awkwardly against the limitations listed, but no sentence is redundant.

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

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

An output schema exists, so return values need not be described. With 100% schema coverage, annotations covering safety, and the description supplying usage conditions, exclusions, an example, and the estimate-not-quote caveat, an agent has enough to call it correctly. Minor gap: no mention of depth's effect on the estimate.

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 and depth are already documented with formats and constraints in the schema. The description's worked example reinforces base/quote/amount but adds nothing about the optional depth parameter, so it neither compensates nor regresses. 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 — estimate slippage and average price for buying an amount of base currency — and immediately scopes it against the sibling tools by contrasting CLOB vs AMM pool. An agent can distinguish this from get_orderbook or get_amm 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' (before placing a market-style trade, to size against depth and compare venues) and an explicit 'Prefer another tool' clause stating it is an estimate rather than a quote and does not split or route. It also names the sibling (amm page) for reading reserves, leaving little 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/openWorld, so safety is covered. The description adds a genuinely non-obvious behavioral detail — that trust lines are 'capped' — which warns the agent about truncated results. It stops short of saying how many or whether other fields are also truncated, 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?

Three labeled segments — content, when to use, boundary/example — with zero filler. The most decision-relevant information (what it returns, when to call it) is front-loaded.

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-value structure need not be explained, and the description still previews the fields. For a single-parameter read tool with full annotation coverage, 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?

Schema coverage is 100%, so the address format ('r..., checksum verified') is already documented. The description goes beyond the schema by supplying a concrete, correctly-formatted example call, which is useful for an agent constructing the invocation. It adds no further constraints, so it lands above the 3 baseline rather than at 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 first sentence names the concrete resource (an XRPL account) and enumerates exactly what the summary contains — balance, sequence, owner count, transfer rate, trust lines. Combined with the title and the explicit scope note, an agent can distinguish it from get_network_health, get_amm, or get_orderbook 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 gives an explicit positive trigger ('inspect an account before building a transaction for it') and an explicit negative boundary ('Not for transaction history, reserves or account flags'). Both when-to-use and when-not-to-use are stated rather than inferred.

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 non-destructive. Description adds a specific failure mode (404 for no pool) beyond annotations. However, it does not cover rate limits, auth requirements, or response caching.

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?

Description is front-loaded with purpose and structured with labels. However, the 'When to use' sentence largely restates the first sentence, adding mild redundancy. Example is useful but overall slightly longer than necessary.

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

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

Given output schema exists (so return values need no explanation), annotations cover safety, and schema covers params, the description completes the picture with usage, alternatives, and failure mode. Nothing critical is missing for a simple 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?

Schema description coverage is 100%, so both parameters are fully documented in the schema. The description's example merely restates the schema's format without adding semantic meaning (e.g., order independence). 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 resource (AMM pool reserves and trading fee) and scope (asset pair). Explicitly distinguishes from sibling estimate_slippage by noting it does not estimate slippage or compare venues. An agent can identify its role 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' and 'Prefer another tool' guidance, naming the alternative (slippage page) and the condition (slippage/venue comparison). Also notes 404 for a pair without a pool, covering failure mode.

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 carry the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context beyond that — it does, by scoping freshness to the latest validated ledger and by stating that a congestion score accompanies the fee tiers. It stops short of describing freshness/rate-limit behavior or the number of tiers, so it is not fully exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what it returns, then when-to-use, then exclusions, then a literal call example. Every clause earns its place with no restatement of the title or name.

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 and the description does not need to enumerate return values, yet it still characterizes the payload (fee tiers in drops plus congestion score). For a zero-parameter, read-only lookup, 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The schema is an empty object and the description correctly shows the invocation as 'get_fee {}'.

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 ('Current XRPL fee tiers in drops') plus the derived value ('congestion score'), which is exactly the kind of specific output framing an agent needs. It also separates itself from siblings by declaring it is 'not a price feed and not a historical series' and describes '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?

Gives explicit when-to-use ('Before submitting a transaction, to choose a `Fee` and to decide whether the network is congested') and explicit when-not ('Not a price feed and not a historical series'). The alternative framing is clear even without naming a specific sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered structurally. The description adds the returned fields and the notion of network-view freshness, but nothing about staleness behavior or failure modes beyond what the annotations and output schema carry.

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?

Labeled sections (When to use / Prefer another tool / Example) front-load the essential routing information efficiently. The literal example call is mildly redundant but harmless.

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, full annotation coverage and an output schema describing return values, the description is complete enough for correct invocation. Little additional context is needed for a zero-arg 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?

Zero parameters, so the baseline is 4. The description and example correctly convey the empty-argument invocation, matching the empty schema.

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

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

States a specific verb and resource ('Latest validated ledger index, hash and close time') and explicitly distinguishes itself from the account endpoint. An agent can identify what this returns 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 an explicit 'When to use' condition (anchoring readings, checking network currency) and a 'Prefer another tool' exclusion naming account/transaction data as out of scope. Routing is fully specified.

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 genuinely new context: it reports the *service's* upstream nodes rather than the caller's own connectivity, which prevents a plausible misuse. It does not discuss caching, freshness, or how health is determined, 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 what, then labeled When to use / Prefer another tool sections, closing with a call example. Every sentence carries distinct information and the structure is immediately scannable.

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

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

For a zero-parameter, read-only health endpoint with an output schema already describing the return shape, nothing an agent needs in order to decide to call it 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 correctly shows the empty-argument invocation (get_network_health {}), which adds nothing beyond the schema but also introduces no 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 resource and scope: overall and per-node health of the upstream XRPL nodes. The subject is unambiguous and, since the siblings (get_fee, get_orderbook, get_latest_ledger, etc.) are all data-fetch tools, no further differentiation is needed.

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 gives when-to-use ('to decide whether to trust or retry data, or to explain a 503 from another endpoint') and a when-not clause ('not a probe of your own connectivity; it reports the service's upstream nodes'). This is the strongest form of 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description still adds real value by disclosing that unfunded offers are filtered out, which materially affects what the returned liquidity means. It does not discuss return shape or depth rounding, but the output schema and input schema cover those.

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, then labels usage, exclusions and an example, so an agent can skim to the relevant clause. Slightly list-like with the repeated labels, but every sentence carries distinct information.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile. Purpose, scope, routing and an example invocation are all present, leaving nothing an agent needs to 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?

Schema description coverage is 100%, so base/quote/depth are already fully documented, including the issuer format and depth rounding rules. The description only supplies a sample call, adding no semantics 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+resource ('CLOB order book for a currency pair') and adds a precise scope qualifier ('with unfunded offers removed'). This distinguishes it from get_amm (AMM liquidity) and estimate_slippage without the agent needing to open 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?

Has an explicit 'When to use' statement and a 'Prefer another tool' clause that names the two relevant alternatives (AMM page, slippage page) and the conditions that select them. Routing is fully determined.

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