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

With no annotations, the description must carry the behavioral burden, and it does disclose the key trait: the tool will automatically spend money by paying the invoice and retrying. It stops short of the details an agent spending real funds needs — payment irreversibility, what happens when the invoice exceeds a limit, failure/refund behavior, or auth implications of the Nostr key.

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

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

Three short sentences, zero filler, and the core mechanism (paywall detection, auto-pay, retry, return value) is front-loaded in a logical order. Nothing is padded or repeated.

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 six-parameter tool with a nested headers object, no output schema, and no annotations — and one that spends real money — the description covers the happy path but omits failure modes, cost safety (maxSats as a spend ceiling), and what the response data looks like. It is adequate but leaves real gaps for a monetary operation.

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 every parameter (url, body, method, headers, maxSats, nostrPubkey) is already documented in the schema, which sets the baseline at 3. The description adds no extra parameter meaning, such as how maxSats interacts with automatic payment or what a trust discount implies.

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+resource ('Fetch a URL that may be behind an L402 paywall') and explains the distinctive mechanism: auto-paying the Lightning invoice and retrying with proof of payment. It is clearly distinguishable from a plain HTTP fetch, but it never references siblings like pay_invoice or pay_lightning_address to clarify why you'd route through this tool instead of paying directly.

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?

Usage is implied by 'may be behind an L402 paywall' — you reach for this when a resource is Lightning-gated rather than reaching for pay_invoice. However, there is no explicit when-to-use/when-not selection guidance and no mention of expected preconditions (e.g., wallet balance, check_balance first), and none of the sibling tools are named as alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses the unit (sats) and that the wallet must be 'connected', but says nothing about whether this requires an authenticated node, potential latency, or that the operation is a safe read.

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 with zero waste; the resource and unit are stated immediately.

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 tool with no output schema, the description is nearly complete: it conveys what is returned (balance) and in what unit (sats). Only minor auth/connection context 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 no parameter semantics to document; the baseline is 4. The description correctly avoids inventing 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?

States a specific verb (check) and resource (current balance of the connected Lightning wallet), plus the unit (sats). It is clearly distinguishable from the payment/invoice siblings, though it never explicitly names an alternative.

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?

Usage is implied — a zero-parameter read tool for querying wallet balance — but there is no explicit when-to-use guidance, no note on prerequisites, and no contrast with siblings such as check_trust or discover_services.

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 exist, so the description carries the behavioral burden. It usefully discloses the return contents (score 0-100, attestation count, attester info), but says nothing about unknown-pubkey behavior, auth requirements, rate limits, or error handling for a network lookup.

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 tightly written sentences with the purpose front-loaded and no filler. Every clause earns its place by stating the resource and the returned data.

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

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

With no output schema, the description compensates by naming the returned fields, which is the key missing piece an agent needs. Gaps remain around failure modes and the shape of 'attester info', but for a one-parameter read lookup it is largely 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?

Schema coverage is 100% and the single required parameter is documented in the schema as a hex Nostr public key. The description only restates that it targets a Nostr pubkey, adding no format or encoding detail beyond the schema baseline.

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

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

States a specific verb (look up) and resource (ai.wot Web of Trust trust score for a Nostr pubkey), which clearly sets it apart from the lightning/payment siblings. It does not explicitly name or contrast with any sibling, but the purpose is 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?

No guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The only context is the implied need to consult trust scores, leaving the agent to infer the scenario.

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 behavioral burden. It does not disclose whether the created invoice expires, whether creation is idempotent, what wallet/account state is required, or what the tool returns. For a mutation tool with zero annotation coverage this is a real gap.

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

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

A single short, front-loaded sentence with no wasted words. It is efficient but so terse that it borders on under-specification rather than tight conciseness.

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 omits the most important operational details: what the call yields (the invoice/BOLT11 string), expiry behavior, and any prerequisites. An agent can guess the purpose but not the result or constraints.

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 (amountSats, description/memo) are already fully documented in the schema. The description mentions none of them and adds no format or constraint detail, so 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 ('Create') and resource ('Lightning invoice') plus intent ('to receive a payment'), distinguishing it from siblings like pay_invoice and decode_invoice which operate on existing invoices. However, it does not explicitly name any sibling for differentiation.

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 clause 'to receive a payment' implies the scenario (you want to be paid), which is adequate implied usage. There is no explicit when-to-use vs. alternatives guidance or exclusion, and nothing routes the agent away from pay_* siblings.

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

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

No annotations exist, so the description carries the full burden. 'Decode ... to inspect' strongly implies a pure read with no side effects, and it usefully discloses the returned fields (amount, description, expiry, payment hash), but it says nothing about error behavior on a malformed invoice or whether network/credentials are needed.

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 front-loaded sentence with the verb, resource, and result fields in a single clause; nothing is wasted and nothing important is buried.

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 trivial one-parameter read tool with no annotations and no output schema, the description covers purpose and the key return values, which is most of what an agent needs. It omits failure modes and the fact that no side effects occur, but those gaps are minor at this complexity level.

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

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

Schema coverage is 100% for the single 'invoice' parameter, so the schema already documents type and meaning. The description adds no format or validation details beyond what the schema provides, making the baseline of 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 a specific verb (Decode) and resource (BOLT11 invoice) and enumerates the returned fields, so an agent can distinguish it from create_invoice/pay_invoice at a glance. It does not explicitly name a sibling or state that it is the read-only parse path, which keeps it just short of a 5.

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 explicit when-to-use guidance, no mention of alternatives (e.g. decode before pay_invoice to verify amount), and no exclusions. The purpose 'inspect' only implies usage, and nothing tells the agent when this is preferable to just calling pay_invoice.

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 behavioral burden. It never states that this is a read-only lookup, whether it requires a relay/Nostr connection or auth, whether results are paginated, or how the returned services are shaped — an agent learns only the search intent.

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 core purpose front-loaded. Slight redundancy in restating 'filter by capability' after the example tags, but nothing wasteful.

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-required-param search with full schema coverage, the description covers the input side, but with no output schema it should say what a result looks like (list of services, fields, ordering). That omission leaves a real gap for a discovery 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 (limit, capability) are already documented in the schema, and the description's capability examples duplicate the schema's own example. Baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb (Search) and resource (agent services) and names the mechanism (decentralized service discovery on Nostr). No sibling tool overlaps this purpose, so an agent can pick it without ambiguity.

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 implies how to use the tool by naming the capability filter and giving example tags, but offers no explicit when-to-use/when-not guidance or alternatives. Adequate but thin on routing context.

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 only discloses that payments run 'in parallel'. For a money-moving tool it says nothing about partial-failure behavior, whether one bad address aborts the batch, auth/spending requirements, reversibility, 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?

Two short sentences, front-loaded with the core action and mode, with no filler. Slightly under-specified rather than verbose, but 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?

A batched payment operation with no annotations and no output schema needs the description to explain failure semantics, return shape, and constraints; the description supplies none of that and even leaves the max-10/concurrency limits to the schema.

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

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

Schema description coverage is 100% and both parameters (payments array, concurrency) are documented in the schema. The description's 'each payment specifies address and amount' merely restates the schema and omits the optional comment field, so it adds no meaning beyond structured data.

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 ('Pay') and resource ('multiple Lightning addresses') plus the parallel execution mode, which is more than a restatement of the title. It implicitly distinguishes itself from the singular sibling pay_lightning_address, but never names pay_lightning_address or pay_batch to make the boundary explicit.

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 mention of the closely related siblings pay_lightning_address (single) and pay_batch. The agent must infer from the plural name alone that this is the multi-address variant.

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 disclosure burden. It mentions parallel execution, but for a payment tool it omits critical behavior: whether payments are atomic or partially succeed on failure, whether Lightning payments are irreversible, authorization requirements, and any retry semantics. This leaves the agent guessing about the highest-risk aspects.

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 with the core action front-loaded; the second sentence earns its place by hinting at the use case, though it is somewhat generic.

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 batch payment tool with no annotations and no output schema, the description should cover partial-failure handling, irreversibility, and what the result reports. None of these are addressed, so an agent cannot reason about how to handle failures across the batch.

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 'invoices' and 'concurrency' (with max/min and default) are already documented in the schema. The description adds no format, ordering, or constraint detail beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource (pay Lightning invoices) with the scoping qualifier 'multiple...in parallel', which naturally distinguishes it from the single-invoice sibling pay_invoice. It does not explicitly name an alternative, but the plural scope is clear.

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?

'Useful for distributing payments to multiple recipients' implies a usage context but stops short of telling the agent when to prefer this over repeated pay_invoice calls or when not to use it. No explicit alternative or exclusion is given.

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 behavioral burden. It mentions the success return value (payment preimage), which is useful since there is no output schema, but omits critical traits for a payment tool: irreversibility, failure behavior, and how maxSats acts as a safety limit.

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 with zero waste, front-loading the core action and following with the key return value. Every word 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?

For a financial transaction tool with no annotations and no output schema, the description is incomplete. It should disclose irreversibility, failure modes, or prerequisites, but instead provides only a minimal success case.

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

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

Schema description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds no additional parameter semantics beyond what is in the schema, making the baseline score of 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 a specific verb (Pay) and resource type (BOLT11 Lightning invoice), clearly distinguishing it from invoice creation or address resolution. However, it does not explicitly differentiate from its closest sibling pay_lightning_address, which handles a different input format.

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 no guidance on when to use this tool versus alternatives like pay_lightning_address or pay_batch. It only restates the operation, leaving the agent to infer that BOLT11 invoices require this tool.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the three-step internal flow (resolve, create invoice, pay), but this is a financial mutation tool and it says nothing about irreversibility, whether maxSats is enforced before signing, or what happens on failure.

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 core action; every clause adds information about the mechanics.

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 annotations and no output schema, the description is only marginally sufficient for a payment tool: it explains the flow but omits failure behavior, safety-limit enforcement, and result expectations.

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 restates the address format already documented in the schema and adds no detail on how maxSats interacts with amountSats.

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 ('Pay a Lightning address') and even outlines the mechanism (resolves, creates invoice, pays). However, it does not differentiate itself from the closely related sibling pay_addresses, so an agent cannot tell the two apart from the text alone.

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 indication of when to use this versus pay_invoice, pay_addresses, or resolve_lightning_address. With several payment-adjacent siblings, the absence of routing guidance is a real gap.

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 what data is retrieved, which signals a read-only operation, but says nothing about errors for unresolvable addresses, network/auth requirements, or idempotency.

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, zero waste, front-loaded with the verb and resource, and the outcome payload is tacked on efficiently.

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 one-parameter read tool with no output schema and no annotations, the description covers purpose and expected return fields well. Minor gaps remain around failure modes and timing, but nothing essential to invoking it correctly is missing.

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

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

Schema coverage is 100% for the single 'address' parameter, so the baseline is 3. The description restates the user@domain.com format but adds no syntax or validation detail beyond what the schema already documents.

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 (Resolve) and resource (Lightning address), and even names the concrete return payload (LNURL metadata, min/max sendable amounts, callback URL). It implicitly separates itself from pay_lightning_address by being a lookup rather than a payment, but never explicitly references the sibling.

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 verb 'Resolve ... to get metadata' implies this is a read/pre-flight lookup, which an agent can infer is appropriate before paying. However there is no explicit when-to-use, when-not-to-use, or routing to pay_lightning_address.

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