Send QUAI (Two-Step Confirmation)

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

The description adds substantial behavior beyond the annotations: the mandatory two-step confirmation, password only held in memory and never stored or logged, automatic ETX handling with slower finality, and the QUAI-to-Qi conversion path. This is exactly the kind of non-obvious behavior an agent needs, and it does not contradict the destructiveHint/readOnlyHint annotations.

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 longer than average, but every sentence earns its place: purpose, sharding/ETX behavior, conversion context, two-call workflow, and security guarantee. It is front-loaded with the core action and then layers necessary procedural detail.

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 destructive, non-idempotent mutation tool with no output schema, the description is unusually complete. It tells the agent exactly what the preview returns, when the password is required, what confirmationToken is, and what happens in the ETX and conversion cases. There is very little left for the agent to infer.

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 enhances this by explaining the lifecycle of confirm, password, and confirmationToken across the two required calls, and it contextualizes amount as QUAI not wei, matching but reinforcing the schema.

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 verb and resource: 'Send QUAI from a wallet in this server's encrypted store to a recipient address.' It goes further by distinguishing same-zone sends, ETX sends, and QUAI-to-Qi conversions, making it easy to separate from sibling tools like get_conversion_rate and send_qi.

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 explicit workflow guidance: always requires two calls, first without confirm for a preview, then with confirm, confirmationToken, and password to broadcast. It points to get_conversion_rate as a quote-without-sending alternative. However, it does not explicitly say 'for pure Qi sends use send_qi,' so the exclusion of a close sibling is left implicit.

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