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

With no annotations provided, the description carries the full burden and does so: it discloses that real on-chain payment occurs, that each invocation creates a new invoice, that retrying after a paid error is dangerous and must be replaced by fulfill_payment with recovery fields, and what the result's `vpn` object contains. These are exactly the irreversible-side-effect and idempotency facts an agent needs before calling a payment 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?

Front-loaded with the preferred-tool marker and the workflow, and nearly every clause carries operational weight (no-retry, invoice creation, recovery path). It is dense to the point of being hard to scan, with several compound sentences packed into one block, but little is genuinely expendable.

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 high-stakes payment tool with no annotations and no output schema, the description covers the workflow, the failure/recovery path, and the shape of the returned `vpn` credentials. The remaining gap is the semantics of `country` and `network`, which an agent would have to guess at.

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% across four parameters. The description does add real meaning for `dry_run` (it creates a new invoice, so don't chain it into a buy) and points to list_vpn_catalog's `services` field as the way to choose `plan`, but `country` and `network` are never mentioned, leaving half the parameters undocumented anywhere.

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 ("Buy VPN") and immediately enumerates the full operation chain: quote → pay on-chain → fulfill → save credentials. This makes it clearly distinguishable from the sibling tools sign_and_pay and fulfill_payment, which are individual steps of that chain.

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 marks itself as PREFERRED, says to call ONCE per purchase, forbids curl/shell against /pay, forbids the dry_run-then-buy sequence with a stated reason (each quote creates a new invoice), and routes the agent to fulfill_payment instead of retrying on post-payment errors. When-to-use, when-not-to-use, and the alternative are all named.

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 load well: it declares the read-of-prior-artifacts model, that no funds move and no invoice is created, and describes the return shape including socks5_port/socks5_connection_string conditionally. It stops short of stating idempotency or what happens if the settlement_tx was already redeemed, which would matter for a recovery operation.

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

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

Front-loads the critical constraint ('Recovery only') in the first three words, then layers requirements, exclusions, and return shape. 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?

With no annotations and no output schema, the description covers everything an agent needs: when to call, what to supply and from where, what it explicitly must not do, and what the response contains. The absence of structured data is fully offset.

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 0%, so the description must compensate, and it does: it names all four required parameters and, crucially, tells the agent where they come from (a prior buy_vpn/sign_and_pay). The optional 'country' parameter is never explained, leaving one 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?

States a specific verb (exchange) and resource (an already-broadcast payment → VPN credentials) and immediately scopes it as 'Recovery only.' It is clearly distinguishable from buy_vpn and sign_and_pay, which it names as the origin of its inputs.

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 an explicit trigger ('Use when fulfill failed after payment') plus an explicit prohibition ('never call buy_vpn again') and states what it does not do (no new invoice, no money sent). An agent has an unambiguous decision rule.

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 and does reasonably well: it labels the operation as a listing, names the data source (X402_BASE_URL discovery), and explains the conditional meaning of `port` vs `socks5_port` so the agent won't misreport capabilities. It says nothing about failure modes, network/config prerequisites, or whether results are cached or live.

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 purpose is front-loaded in the first clause, and the second sentence adds only decision-relevant detail about `services` and the two port fields. The second sentence is long and parenthetically dense, but every clause maps to a field the agent must interpret.

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?

No output schema exists, yet the description compensates by documenting the plan record fields, the country-code list, and the relationship between `services` and the two port fields. An agent has enough to call it and to interpret the response without guessing.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no input semantics to explain. All descriptive effort is correctly spent on output fields rather than invented 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 and resource ("List purchasable VPN plans") and enumerates the returned attributes (id, USD price, duration, server country codes), so the agent knows exactly what this call produces. It does not explicitly name or contrast with the sibling buy_vpn, leaving the read-vs-purchase distinction to be inferred from the word "List".

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 a clear usage context: consult this before recommending or purchasing a plan, and specifically check `services`/ports before telling a user which plan supports SOCKS5. It stops short of naming when not to use it or pointing to buy_vpn as the follow-up step, so no explicit alternative is offered.

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 most of it: it discloses that real value moves on-chain, names the returned fields (payment_signature, settlement_tx), states what is deliberately omitted (VPN credentials), and warns about double charging. It stops short of covering failure/retry behavior, wallet prerequisites, or what dry_run actually changes — material gaps for an irreversible money-moving call.

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 'DEBUG ONLY' warning, then the capability, then the mandatory next step. Every clause carries operational consequence; nothing 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?

For a no-annotation, no-output-schema, money-moving tool the description does well on return values and workflow ordering. But it never explains the required accepts payload or dry_run, so an agent still lacks what it needs to construct a correct call in this deliberately dangerous path.

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% and the required `accepts` parameter is a nested array of objects with seven required subfields. The description only implicitly touches `invoiceNo` (via the fulfill_payment matching requirement) and is silent on `dry_run`, `network`, and the entire accepts structure, leaving an agent to guess at payment-critical fields.

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 ('Broadcasts on-chain payment') and immediately bounds scope with 'does NOT fetch VPN credentials'. It distinguishes itself from siblings by naming buy_vpn and fulfill_payment, so an agent can place it in the workflow without opening any schema.

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

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

Explicit exclusions ('Prefer buy_vpn', 'DEBUG ONLY') plus a hard mandatory follow-up ('you MUST next call fulfill_payment with the same invoice_no') and a named failure mode ('double charge'). The when-not, the alternative, and the cost of getting it wrong are all 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 does disclose one meaningful behavioral trait (addresses only, never private keys), which signals a safe read, but says nothing about permissions, what happens when no wallets are configured, or any 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?

A single sentence with no filler, front-loading the verb and resource and appending the one detail worth knowing (no private keys). 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?

For a simple zero-param read tool with no output schema, the description states what is returned at a high level (configured wallet addresses) and removes the obvious security ambiguity. It could say a bit more about the return shape or the empty-configuration case, but it is essentially 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the empty schema already shows. Baseline 4 for a parameterless 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 gives a concrete verb+resource ("Show which wallets are configured") and adds a scope qualifier about what is and isn't returned. It is clearly distinguishable from the payment/VPN siblings, though it does not name them explicitly.

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 only implied: an agent would call this to inspect configured wallets. There is no statement of when to use it versus alternatives, nor any prerequisites or exclusions, so it sits at minimum viable.

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