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

With no annotations, the description carries the full behavioral burden. It discloses the returned fields and the 'not opened' edge case, but says nothing about permissions, error behavior, or that the operation is read-only, leaving meaningful gaps for an agent relying on the description alone.

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

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

Two sentences are appropriately sized and front-loaded with the returned data before the edge case. The first sentence is a dense list but avoids waste and stays under the attention budget.

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 one-parameter read tool with no output schema, the description does the important work of listing the returned fields and noting the 'not opened' condition. It remains somewhat incomplete because it never clarifies when to prefer this aggregate info over the more focused sibling tools.

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 single account parameter is already documented in the schema as a Nano address. The description adds no syntax, formatting, or constraint details beyond what the schema provides, so it meets the baseline for high coverage.

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

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

The description clearly identifies the resource (an account) and enumerates the specific data returned: frontier, representative, block count, balance, and open time. It is easy to tell what the tool does, but it does not explicitly differentiate itself from siblings like nano_balance or nano_history.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as nano_balance, nano_history, or nano_receivable. The note about 'not opened' accounts describes an edge case but does not help an agent choose this tool over another.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return semantics (confirmed vs pending, XNO vs raw), which is real context beyond the schema, but says nothing about whether the call is read-only, whether an unopened/unfunded account errors, auth requirements, 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?

One sentence, front-loaded with the core noun (confirmed balance) and finishing with the units. Nothing is wasted, though the phrasing 'what waits for it to receive' is slightly indirect where 'receivable' would be crisper.

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 is the only signal about return values, and it gives only a high-level hint (XNO and raw, confirmed and pending) without indicating structure or field names. For a simple single-parameter read that is borderline adequate, but the no-annotation, no-output-schema combination leaves gaps.

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 single parameter is fully documented in the schema (100% coverage) as a nano_ address, so the schema does the heavy lifting. The description adds no format, validation, or example information beyond what the schema already provides, making the baseline 3 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 the resource precisely: an account's confirmed balance plus the amount pending receipt, returned in both XNO and raw units. It is clearly distinguishable from sibling reads like nano_history or nano_account_info, though it never explicitly names or contrasts with nano_receivable, which covers overlapping pending-funds ground.

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?

No when-to-use guidance, no prerequisites, and no routing to alternatives. An agent cannot tell from the description whether to use nano_balance or nano_receivable to check incoming funds, even though the tools clearly overlap.

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

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

With no annotations, the description carries the full burden and does add real value: it discloses that no key is needed (auth-free), that the amount is price plus identifying raws, and that it targets a configured NANO_PAY_TO address. It omits key behaviors such as what happens if both amount_usd and amount_xno are supplied, and how expiry (minutes) affects the invoice.

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 tight sentences, front-loaded on the core concept, with no filler. Slight redundancy in restating 'the price plus a few raw' in prose after already framing the amount, but overall efficient.

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 creation tool with no annotations and no output schema, the description orients the agent well (exact amount, nano: link to show the payer, keyless operation) but leaves the amount-parameter exclusivity and the expiry semantics unexplained, which an invoking agent needs.

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 75%, so the baseline is 3. The description explains the USD/XNO price concept that backs amount_usd and amount_xno, but says nothing about memo or the minutes expiry window, leaving its addition over the schema minimal.

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 resource and its economics precisely (an invoice for a price in USD or XNO paid to NANO_PAY_TO), which distinguishes it from siblings like nano_wait_for_payment and nano_verify_payment. It never uses an explicit verb such as 'create', opening with a noun phrase, so it falls just short of the top score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to create an invoice versus when to use nano_verify_payment or nano_wait_for_payment, nor any prerequisite context. The usage is only inferable from the payment-flow sibling names.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses ordering (newest first) and the pagination mechanism, but omits whether this is strictly read-only (implied), rate-limit behavior, the default page size of 10, and what happens when `before` points to an unknown block. Adequate but incomplete for a node-backed query.

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 short sentences, front-loaded with the resource and ordering, then the paging rule. Nothing is wasted and 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?

There is no output schema and no annotations, so the agent is left guessing the shape of returned entries (hashes, amounts, counterparties) and whether results are limited to confirmed blocks. For a 3-parameter listing tool this is adequate but leaves real gaps.

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 67%: `before` and `account` are already documented in the schema, while `count` has only type/default/bounds. The description reinforces the paging semantics of `before` as a block hash but adds no new format or validation meaning 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 the resource precisely ('an account's latest sends and receives') and its ordering ('newest first'), which is more than a restatement of the name 'History'. It does not explicitly contrast with siblings like nano_balance or nano_receivable, but the scope is clear enough that an agent can distinguish a transaction listing from a balance or receivable lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one conditional usage rule — use `before` to page back — which is genuinely actionable. However, it never says when to choose this tool over nano_account_info or nano_receivable, nor any precondition (e.g., account must exist). Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden. It usefully discloses the data source ("the median of public price feeds"), signaling an aggregated rather than exchange-specific rate, but omits auth needs, rate limits, and what the response contains for a query with no amount.

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 short sentences, front-loaded with the resource and followed by the invocation hint; 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?

There is no output schema, so the description should ideally describe the returned shape (rate alone vs. converted amount) and the no-parameter default behavior. It covers the core purpose but stops short of the completeness an annotation-free, output-schema-free tool needs.

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 50% (only amount_xno is described in the schema), and the description compensates partially by framing the two parameters as an either/or conversion input. It does not explain what happens when both or neither are supplied, nor that both are optional, leaving a real gap for a 2-param tool.

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

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

The description states a specific resource (XNO price in US dollars) and a conversion capability, which is unambiguous and clearly distinct from the wallet/payment siblings. It does not name any sibling, but none of them overlap, so differentiation is implicit rather than stated.

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?

"Give amount_usd or amount_xno to convert" implies how to invoke it for conversion, but says nothing about when to call it with neither parameter (plain price lookup) or whether the two parameters are mutually exclusive. No alternatives exist among siblings, so there is no when-not guidance to give, but the invocation contract is left partly 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?

With no annotations, the description carries the full behavioral burden. It usefully states that results are ordered largest first and include sender and amount, but it omits pagination behavior, the count limit, read-only safety context, and any authentication requirements.

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 a single compact sentence with no filler. It is front-loaded with the core pending-receivable concept, though the phrasing 'Sends waiting' is slightly awkward.

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 three-parameter list tool with no output schema and no annotations, the description provides only partial context. It covers the core return content but omits pagination details, count limits, and filter behavior, leaving an agent with open questions about 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 coverage is 67%, with account and min_xno described in the schema but count left undocumented. The description adds ordering context but does not explain count, pagination, or how min_xno filters results, so it only partially compensates for the coverage gap.

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 conveys that this tool returns pending sends awaiting receipt by an account, with ordering and included fields. The verb is implicit rather than explicit, and it does not directly distinguish itself from siblings such as nano_history or nano_wait_for_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives like nano_history, nano_wait_for_payment, or nano_verify_payment. The agent must infer the use case from the tool name and description alone.

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

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

Goes well beyond the annotations: it discloses that the tool first sweeps in pending receivable funds, then enforces a per-send limit, a 24-hour cap and an allowlist before sending exactly once. It also explains retry safety semantics ('a retry then never pays twice') and demands user confirmation, which is exactly the risk context an agent needs for a destructiveHint=true, openWorldHint=true money-movement 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?

Three tight sentences, front-loaded with what the tool does and the funds-moving risk, then the internal checks, then the idempotency and confirmation rules. No filler, and each sentence carries a distinct operational requirement.

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 covers what matters: real funds move, what internal validation happens, the retry contract, and the required user-confirmation step. Combined with 100% schema coverage and the annotations, an agent has everything needed to call this safely.

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 'to', 'amount_xno', 'allow_repeat' and 'idempotency_key' are already documented at the field level, which sets the baseline at 3. The description adds the payment-lifecycle meaning of the idempotency key (new per payment, reused on retry, never double-pays), but that largely restates the schema's own wording and says nothing extra about amount format or allow_repeat.

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 ('Sends real XNO from the scoped wallet') and immediately scopes it to the wallet the agent is operating on, which separates it from read-only siblings like nano_balance, nano_receivable and nano_history. An agent can tell this is the actual payment-execution tool, not the invoice or verification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: pre-checks run automatically, a fresh idempotency_key per payment with reuse on retry, and an explicit instruction to confirm amount and address with the user before sending. It never names an alternative sibling (e.g. nano_create_invoice for requesting payment, nano_verify_payment for checking one), so the when-not-to-use side 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?

With no annotations, the description carries the full burden and does add real value by enumerating the possible result states (paid, pending, waiting, expired, wrong, invalid, used, unknown), which tells the agent this is a non-mutating status probe. However, it omits whether the call is read-only, whether it requires an API key, and whether 'since' matters for invoice mode.

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 two-mode structure is front-loaded and dense, with the state enumeration appended efficiently. Every clause carries information, though the single run-on sentence merging mode explanation and parameter listing is slightly hard to parse.

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

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

For a 6-parameter tool with no annotations and no output schema, the description does the core job of explaining both modes and the possible return states. But it leaves required/optional behavior (0 required params is surprising and unexplained) and the amount_raw vs amount_xno choice unresolved, so an agent could still call it incorrectly.

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 50%; the description usefully explains hash as the payer's block hash, ties to/amount/since together in the block-check mode, and clarifies 'since' semantics. It fails to disambiguate amount_raw from amount_xno, both of which map to the vague 'exactly amount' phrasing, leaving one of the undocumented parameters unexplained.

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 operation ('checks') and clearly delineates two distinct modes: invoice verification via invoice_id and raw block/payment verification via to/amount/since. It is specific enough that an agent can tell it apart from nano_create_invoice or nano_send, though it never names the nearest sibling nano_wait_for_payment to contrast polling vs waiting.

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 'Either...or' phrasing explains which parameters belong to which mode, but there is no explicit when-to-use guidance and no mention of when to prefer this over nano_wait_for_payment or nano_history. An agent must infer the polling vs waiting distinction from the sibling names alone.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the key traits: it blocks up to timeout_seconds, hard-caps the wait at 120 seconds, and returns on any of three distinct states, including the subtle 'payment seen but not confirmed (pending)' case. It stops short of stating permissions/rate limits or what happens on timeout, and the absence of an output schema means return-value behavior is only partially covered.

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 tight sentences with the blocking semantics and terminal states front-loaded, and no filler. The parenthetical cap and the trailing retry hint both earn their place, though the phrasing around the parenthetical is slightly dense.

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 blocking poll with no annotations and no output schema, the description covers the important 'when does it return' question but not 'what does it return' — an agent cannot tell whether a timeout yields an error, a null, or an unpaid status. Given the tool's complexity this is close, but the missing return-on-timeout semantics leaves a real 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 description coverage is 0%, so the description must compensate. It explains that timeout_seconds bounds the wait and is capped at 120 (echoing the schema's maximum), but says nothing about invoice_id beyond the implied 'wait for this invoice'. That is adequate but not full compensation for two undocumented parameters.

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

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

The description uses a specific verb and resource ('Waits ... until the invoice is paid') and enumerates the three terminal conditions (paid, pending, expired), so an agent understands exactly what the call blocks on. It does not explicitly differentiate itself from the closest sibling, nano_verify_payment, leaving some ambiguity about which to choose for a one-shot check.

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?

'Call it again to keep waiting' implies the polling pattern, which is useful usage context. However, there is no explicit guidance on when to use this versus nano_verify_payment, nor any stated prerequisites such as the invoice needing to exist or which states are worth retrying on.

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

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

With no annotations, the description carries the full burden, and it does add two real behavioral facts: the wallet is 'scoped' to sending, and the seed is 'never' returned. That security disclosure is genuinely useful. It still omits whether the call is read-only, what auth it needs, or the return shape, so it falls short of full transparency.

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

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

A single sentence, front-loaded with the scope ('The scoped send wallet') before the field list, with no filler. Slightly dense/list-like, but every clause earns 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 must convey return contents, and it does: sending-enabled flag, address, balance, limits, and 24-hour remaining amount, plus the seed exclusion. The only material gap is the absence of routing guidance against overlapping siblings.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly avoids inventing arguments.

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 identifies the resource ('the scoped send wallet') and enumerates what it exposes (address, balance, limits, 24h remaining, whether sending is on), so an agent can infer it is a read of wallet state. However, there is no explicit verb — it is a noun phrase, not 'Get/Retrieve the send wallet' — and it does not distinguish itself from sibling nano_balance or nano_account_info, which plausibly overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives despite a crowded sibling set (nano_balance, nano_account_info, nano_send). The agent must guess whether this is the right call for balance or wallet-config questions.

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