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

No annotations are present, so the description carries the full burden. The verb 'Show' implies a read-only operation, and the field list clarifies what is returned. However, it does not explicitly state that there are no side effects, or disclose whether the data is real-time or cached, which would add valuable behavioral context.

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, the first front-loads the purpose and lists the returned metrics, the second offers a practical usage hint. Every word earns its place; no redundancy or fluff.

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 0-parameter status tool, the description is quite complete. It covers what is returned (the field list serves as a de facto output contract), when to use it, and the overall purpose. It does not discuss errors or pagination, but those are unlikely to matter for a read-only status check.

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

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

The tool has zero parameters, and the empty schema is fully covered. The baseline for 0 params is 4, and the description adds no parameter details because none are needed. It appropriately focuses on output semantics instead.

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

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

The description opens with 'Show the current spend-budget state,' using a specific verb and resource. It enumerates five distinct budget metrics (rolling-24h spent, daily cap, lifetime spent, optional total cap, per-invoice max), clearly distinguishing this tool from siblings like nwc_get_balance or nwc_list_transactions.

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 explicitly states a use case: 'Useful before attempting a payment to know whether it will be allowed.' This provides clear context for when to invoke the tool, but it does not mention alternative tools or when not to use it, stopping short of a full 5.

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 provided, the description carries the full burden. It discloses that the token is single-use/consumed and that safety checks (budget, allowlist) are re-run. This is valuable behavioral context beyond the bare action. It could also mention failure modes or idempotency, but what is present is substantive.

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

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

Two sentences, no wasted words. The first sentence immediately states the action and object, and the second provides key conditions and behavioral traits. Excellent front-loading and structure.

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 tool with one parameter, no output schema, and no annotations, the description covers purpose, usage condition, token lifecycle, and safety re-check. It does not describe the return value or error behavior, but given its simplicity and the absence of an output schema, the description is largely complete. A 5 would require more detail on expected outcomes.

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 input schema already explains the token parameter as 'the confirmation token returned by a previous spend tool call' with 100% coverage. The description adds the adjective 'one-time' and clarifies token consumption, but this is more behavioral than parameter-specific. The description does not significantly enhance understanding of the parameter beyond the schema, so 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?

The description clearly states the tool executes a previously prepared payment using a one-time token, which distinguishes it from siblings like nwc_pay_invoice that initiate new payments. The verb 'execute' and resource 'previously prepared payment' are specific and unambiguous.

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 explicitly notes the tool is only meaningful when NWC_REQUIRE_CONFIRM=true, giving a clear condition for use. It also implies the workflow: after a spend tool call returns a token, this tool confirms it. However, it does not explicitly name alternatives or state when *not* to use it, so it falls short of a 5.

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 provided, the description carries the full burden. It clearly states the operation is performed 'locally (no network call)' and enumerates the return fields (amount in sats, description, payment hash, expiry, payee pubkey, network). This gives a good sense of what the tool does, though it doesn't mention error handling or validation details.

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 two sentences, front-loaded with the main action, and includes a clear use-case pointer. Every sentence adds value: the first explains what/where, the second explains when and why. No fluff.

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 single-parameter tool with no output schema, the description is complete: it states the input type, the execution context (local, no network), the returned fields, and a practical usage scenario. The sibling list reinforces its role, but the description itself is sufficient.

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 input schema already has 100% coverage for the single parameter 'invoice' with description 'The bolt11 invoice string to decode.' The tool description does not add additional meaning to that parameter beyond confirming it's a bolt11 invoice, 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?

The description clearly states the tool's action: 'Decode a bolt11 Lightning invoice locally'. It specifies the resource (bolt11 invoice) and the verb (decode), and distinguishes from siblings like 'pay_invoice' by emphasizing the local, non-network nature and its role as a pre-payment 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?

The description provides explicit when-to-use guidance: 'Use this before pay_invoice to confirm the invoice contents.' It also implies a context (local decode, no network). However, it does not mention when not to use it or contrast with alternative tools like 'lookup_invoice', so it falls short of full 5.

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?

No annotations are provided, so the description bears full responsibility. It clearly indicates a read-only-ish action ('Return') but does not discuss safety, side effects, errors, or prerequisites beyond mentioning a 'connected wallet'. For a simple getter, this is adequate but not rich.

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, front-loaded sentence containing only essential information. No wasted words, and the key details (action, resource, unit) are all present.

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 the simplicity of the tool (no parameters, no output schema, no annotations), the description covers the essential information: what is returned and in what units. It could optionally mention error behavior, but the description is complete enough for a basic balance query.

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

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

The tool has zero parameters, so the baseline is 4. The description adds semantic value by specifying the return unit ('satoshis'), which is not present in the empty schema. No further parameter detail is possible or needed.

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 specifies a clear action ('Return') and a distinct resource ('current spendable balance of the connected wallet') with units ('satoshis'). This unambiguously distinguishes it from sibling tools focused on invoices, payments, and wallet info.

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 implicitly defines when to use the tool (when a balance is needed), but it does not explicitly state exclusions or alternatives, such as whether nwc_get_info might also provide balance. Without sibling differentiation, it lacks clear usage guidance beyond obviousness.

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 burden. It lists the returned data fields and implies a read-only operation by saying 'call this first', but it does not explicitly state whether it mutates state, requires auth, or has side effects. For a simple info call, this is adequate but not rich.

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

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

Two sentences, front-loaded with the primary action and immediate outcome, no filler. Every word adds value.

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 parameterless info tool, the description lists return values and usage context. No output schema exists, but the field list provides sufficient expectation. Missing details like exact format of capabilities are not critical for 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?

The tool has zero parameters, so schema coverage is 100% trivially. The description does not need to explain parameters. The baseline of 4 is appropriate.

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

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

The description clearly states a specific verb ('Return') and a specific resource (connected wallet's capabilities, methods, pubkey, network, alias, color). This distinguishes it from siblings like nwc_get_balance or nwc_list_transactions, making the tool's purpose unmistakable.

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 provides explicit timing guidance ('Call this first in any session') and explains the benefit ('discover what the wallet supports'). While it doesn't explicitly name alternatives or when not to use, the context strongly implies it as a discovery tool before other operations.

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?

No annotations are provided, so the description carries the full burden. The verb 'List' implies a read-only operation and the description adds filter semantics, but it does not disclose pagination behavior, default ordering, return format, or explicitly state that it is non-mutating. This is adequate but not rich in behavioral context.

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

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

Two sentences, front-loaded with the core purpose, and no redundant words. Every clause adds useful information (resource, filters). This is optimally concise.

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?

The tool has 6 optional parameters, all fully documented in the schema, and no output schema. The description sufficiently conveys that the tool lists filtered transactions. It could mention pagination (limit/offset) or the response shape for full completeness, but the schema already covers parameter semantics, and the operation is simple enough that the description meets the bar.

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% with detailed descriptions for all six parameters. The description only restates the filtering concepts already present in the schema (time range → from/until, direction → type, unpaid → unpaid). It adds no additional syntax, default-value, or relationship context, 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?

The description uses a specific verb ('List') and resource ('transactions on the connected wallet'), and clearly enumerates the filtering axes (time range, direction, unpaid invoices). This strongly distinguishes it from sibling tools like nwc_lookup_invoice, which targets a single invoice.

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 provides clear context: it lists transactions and supports filters. However, it does not explicitly mention when to prefer this over alternatives (e.g., for a single invoice, use lookup_invoice). The absence of exclusions or alternative references drops it from a 5.

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 provided, the description carries the full burden. It discloses the return fields and the condition for preimage ('if settled'), but does not explicitly state that this is a read-only operation, what happens if the invoice is not found, or behavior when both parameters are provided. The description is adequate but lacks some behavioral edge cases.

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 two sentences, front-loaded with the core purpose, followed by returned data and parameter instruction. Every word contributes, with no redundancy or filler.

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

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

For a simple lookup tool with two optional parameters and no output schema, the description covers the key aspects: input alternatives, returned fields, and conditional preimage. It lacks guidance on error handling or conflicting parameters, but given the tool's low complexity, it is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly stating that the two parameters are alternatives ('either payment_hash OR invoice'), clarifying the exclusivity relationship beyond the schema's individual field descriptions. This helps the agent understand how to choose between them.

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 states the tool's function: 'Look up an invoice by payment hash or bolt11 string.' It specifies the verb, resource, and input types, and distinguishes itself from siblings like nwc_decode_invoice by explicitly listing the returned data (state, timestamp, amount, fees, preimage), which implies it retrieves stored invoice status rather than just decoding.

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 parameter usage guidance ('Provide either payment_hash OR invoice') but does not explicitly differentiate when to use this tool versus siblings like nwc_decode_invoice or nwc_list_transactions. The intended use case is implied by the description of returned state information, but no explicit alternatives or exclusions are mentioned.

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 provided, the description takes on full responsibility for behavioral disclosure. It explicitly states that the tool 'does not move funds; only generates a payment request,' addressing the key safety concern for a financial tool. It also reveals the return values ('Returns the bolt11 string and payment hash'), which is helpful. However, it does not mention other behavioral aspects like whether the invoice is stored, persisted, or has side effects beyond generation, so it falls short of a perfect score.

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 two sentences long, front-loaded with the core action, followed by a concise safety note and return value summary. Every sentence earns its place with no fluff or repetition. The structure is efficient and 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 simple 3-parameter tool with no output schema, this description covers the essential aspects: what it does, its safety profile, and what it returns. It does not explicitly state whether the invoice is persisted or usable immediately, which could be relevant context for integration. However, the tool's purpose is straightforward and the description is sufficient for an agent to invoke it correctly in most cases.

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%, meaning all three parameters (amount_sats, description, expiry_seconds) are fully described in the schema with types and limits. The description adds no additional meaning beyond what the schema already provides—it simply mentions 'amount in sats,' which is already in the schema. Per the rubric, the baseline of 3 applies when schema coverage is high, and the description neither compensates nor introduces ambiguity.

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 states a specific action: 'Create a bolt11 Lightning invoice for the given amount in sats.' This is a unique verb+resource combination that unambiguously distinguishes it from sibling tools like pay_invoice or lookup_invoice, which serve different functions. The resource (bolt11 invoice) is specific and leaves no doubt about the tool's purpose.

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 provides no explicit guidance on when to use this tool versus the siblings. It does not say 'use this when you need to receive payment' or contrast with pay_invoice. The phrase 'Safe — does not move funds; only generates a payment request' hints at its non-destructive nature, but this is more about safety than usage context. There is no mention of appropriate scenarios or exclusions, leaving the user to infer from the tool name and sibling list.

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 excels. It discloses that each invoice is independently decoded and safety-checked, that the batch sum is checked against budget caps upfront, that no payments are sent if any pre-check fails, and that partial failures do not roll back settled invoices. This is rich behavioral detail that goes beyond a simple 'pays invoices' statement.

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 two sentences: the first states the core purpose, the second explains the safety checks and execution model. Every sentence earns its place with no redundancy or filler. The critical information 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?

For a multi-invoice payment tool with safety checks and no output schema, the description covers the essential behavioral context: pre-checks, budget caps, sequential execution, and no rollback. However, it leaves ambiguity about what happens when a single invoice fails—does the batch stop, skip, or continue? It says 'a failure mid-batch does not roll back already-settled invoices' but does not clarify whether subsequent invoices are still attempted. This minor gap prevents a 5.

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 schema already documents the invoice string and amount_override_sats fields. The description adds value by explaining how the invoices array is processed: each invoice is checked independently, and the batch sum is budget-checked upfront. This clarifies the group-level semantics of the array parameter beyond what the schema's item description provides.

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 opens with 'Pay multiple bolt11 invoices sequentially in one tool call,' which clearly identifies the verb (pay), resource (bolt11 invoices), and scope (multiple, sequential). This distinguishes it from siblings like nwc_pay_invoice, which handles single invoices, and nwc_pay_lnurl/keysend for non-bolt11 methods.

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

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

The description implies when to use this tool: when there are multiple bolt11 invoices to pay in a single call. It does not explicitly name alternatives or state 'for single invoice use nwc_pay_invoice,' but the phrasing 'multiple... in one tool call' provides a clear context. No exclusions or when-not-to-use are given, so it falls slightly short of a 5.

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 discloses the safety pipeline (read-only gate, destination allowlist, budget cap), the conditional confirmation token, and the success return (preimage + fees). It could be more explicit about error scenarios or the exact meaning of the read-only gate, but it is substantially transparent.

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 three well-structured sentences that front-load the main action and then deliver safety behavior, confirmation flow, and return value. Every sentence adds value with no redundancy or fluff.

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 payment tool with no output schema and no annotations, the description covers the safety checks, conditional confirmation, and return value. It lacks error-handling details and the exact confirmation token format, but the reference to nwc_confirm_payment covers the follow-up step, making it adequately complete for an agent.

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 both parameters (invoice and amount_override_sats) are already well-described in the schema. The description's mention of 'bolt11' and local decoding adds minimal extra context, and it does not elaborate on parameter syntax beyond what the schema provides. 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?

The description opens with 'Pay a bolt11 Lightning invoice,' clearly identifying the action and resource. It further distinguishes from siblings by noting the local decode and safety pipeline, and implicitly excluding other payment types (e.g., keysend, LNURL) through tool naming and context.

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 provides clear context for when to use this tool (bolt11 invoices) and explicitly explains the confirmation flow tie-in with nwc_confirm_payment if NWC_REQUIRE_CONFIRM=true. It doesn't explicitly name alternatives like nwc_multi_pay_invoice or nwc_pay_lightning_address, but the sibling list makes those distinctions obvious.

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?

No annotations are provided, so the description carries full burden. It discloses no payment hash receipt, weaker safety surface, and the full safety pipeline (read-only gate, allowlist, budget cap, optional two-step confirmation). This is rich behavioral context beyond the 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?

Three sentences, front-loaded with the core purpose, then caveats and safety details. Every sentence adds unique value without waste.

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

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

Given the complexity of a payment tool with no annotations and no output schema, the description covers the essential aspects: default-off toggle, safety pipeline, invoice comparison, and what to expect (no payment hash). It is sufficiently complete for an agent to decide and invoke correctly.

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

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

Schema coverage is 100%, so the description need not elaborate on parameters. It does add minor value by mentioning TLV records usage examples (e.g., podcasting 2.0 metadata), but the schema already documents all fields well. This meets the baseline for high schema 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 states 'Send sats directly to a node pubkey via keysend (spontaneous payment, no invoice),' which specifies the exact action, resource, and method. It distinguishes from siblings like nwc_pay_invoice and nwc_pay_lightning_address by emphasizing pubkey-based, no-invoice payments.

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 provides usage context: 'Default-off — must be opt-in via NWC_KEYSEND_ENABLED=true' and 'Use bolt11 invoices when available.' This tells when to use the tool and when to prefer alternatives, plus notes it's a power-user feature.

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?

No annotations are provided, so the description carries the full burden. It discloses a significant amount of behavioral detail, including the safety pipeline (read-only gate, allowlist, budget cap, optional two-step confirmation) and the return of the preimage on success. This goes beyond typical descriptions, though it omits potential failure modes or specific permission 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 extremely concise, consisting of exactly two sentences. It front-loads the core action ('Pay a Lightning Address') and then efficiently summarizes the technical flow and safety checks. Every sentence earns its place without 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?

Given the tool's complexity (payment operation, no output schema, no annotations), the description is quite complete. It explains the end-to-end process, mentions the safety pipeline, and notes the return value. It also implicitly connects to the sibling nwc_confirm_payment via the two-step confirmation. It lacks explicit error scenarios, but the coverage is strong for a tool of this type.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter; the schema covers address format, comment behavior (LUD-12), and amount constraints. The description's mention of 'budget cap' indirectly relates to amount_sats but not in a parameter-specific way.

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 states the tool's purpose with a specific verb+resource: 'Pay a Lightning Address'. It also distinguishes itself from sibling tools by explicitly mentioning the resolution of LNURL-pay to a bolt11 invoice, which sets it apart from tools like nwc_pay_invoice or nwc_pay_lnurl.

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

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

The description implies usage context by explaining the tool's workflow (resolving an address to an invoice), but it does not explicitly state when to use this tool versus alternatives like nwc_pay_invoice or nwc_pay_lnurl. It provides no exclusions or when-not-to-use 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?

With no annotations, the description carries the full disclosure burden. It goes beyond 'pay' by detailing the internal pipeline: decodes LNURL, resolves pay request, runs safety pipeline (read-only gate, allowlist check, budget cap, optional two-step confirmation). This provides crucial behavioral context about constraints and side effects.

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 compact and well-structured: the first sentence states the core function, the second explains the internal process, and the third provides an alternative tool. Every sentence serves a purpose, with no redundancy or 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?

The description covers purpose, process, and constraints thoroughly, but there is no output schema and no mention of what the tool returns. Since optional two-step confirmation is mentioned, the agent is left without guidance on how to handle that flow or what response to expect, creating a notable gap for a payment 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%, as all three parameters are documented in the input schema including format, range, and LUD-12 comment support. The description adds no parameter-specific information beyond what the schema already states, so the baseline score 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?

The description uses a specific verb ('Pay') with a clear resource ('raw LNURL-pay endpoint'), and immediately distinguishes itself from the sibling tool nwc_pay_lightning_address. It also specifies the input format (bech32 lnurl1... string), leaving no ambiguity about what this tool does.

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?

Clear guidance is provided: use this tool for raw LNURL strings, and use nwc_pay_lightning_address for name@domain.tld addresses. This explicit alternative tells the agent exactly when to choose this tool over a closely related sibling, qualifying as strong usage guidance.

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