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

With no annotations, the description carries the full burden and does substantial work: it discloses the return shape (signed receipt, FAITHFUL/DEVIATED/NOT_EXECUTED/UNDETERMINED verdicts, price delta, binding ids, verify URL) and warns the verdict is not authorization to act. It does not state auth requirements, idempotency/replay behavior, or whether a receipt is persisted on failure — gaps for a signing 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 core action, then conditions, then return values — a sensible ordering in three sentences. The 'Use it only after the trade settled. Do not use it before execution' pair is mildly redundant, and the parenthetical '(or settlement status)' is a hedge that could be stated more crisply.

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?

Five parameters with nested objects, one enum, no output schema — the description compensates well by enumerating the returned fields and verdict values. It is still thin on the provenance of the 'pre-trade handle' and the 'signed guard decision', which an agent needs in order to assemble valid inputs across a multi-step flow.

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 60% and the schema already documents receipt/decision as mode-conditional and signature as a Solana signature. The description adds the mapping of modes to their inputs (pre-trade handle plus settlement transaction vs. guarded swap), but contributes no format, shape, or constraint detail for the nested receipt/decision objects beyond what the schema states.

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 a specific verb+resource pair — 'issue a signed execution-price receipt' — and names both operating modes (receipt from a pre-trade handle + settlement tx, or settle a guarded Base/Solana swap). An agent can tell this is a post-execution close-out tool distinct from prepare_swap or check_trade_safety without opening the schema.

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

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

It gives an explicit gate — 'Use it only after the trade settled. Do not use it before execution' — plus a negative constraint that the verdict is not principal authorization. What's missing is naming the upstream sibling (e.g. prepare_swap / begin_trade_evidence) that produces the pre-trade handle, so the agent must infer which tool precedes it.

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