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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the network fee is deducted from the amount, so the recipient gets amount minus fee – a critical detail. However, it does not mention whether the operation is reversible, what the response contains, or any idempotency behavior, leaving some gaps.

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 a single sentence with a dash, efficiently front-loading the core action and then adding the essential fee detail and a usage pointer. Every clause earns its place, with no 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 tool has 5 parameters and no output schema or annotations, so the description must carry more weight. It covers the core withdrawal action, fee deduction, and a workflow hint, but omits param semantics for owner and idempotencyKey and says nothing about the tool's response. This leaves an agent without guidance on important inputs and expected output.

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 schema has zero descriptions, so the tool description must compensate. It adds meaning for 'amount' (subject to fee deduction) and 'address' (on-chain destination), and implicitly for 'network' via the network fee. It offers no explanation for 'owner' or 'idempotencyKey', which are left entirely to the schema's bare type strings.

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 'queue' and resource 'withdrawal to an on-chain address', clearly distinguishing it from sibling tools like cancel_withdrawal and list_withdrawals. The inclusion of 'on-chain address' also separates it from withdraw_task_comment, making the purpose 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 provides a clear usage hint: 'GET the wallet first for the quote', indicating a prerequisite before invoking this tool. It implies when to use (to queue a withdrawal) but does not explicitly mention alternatives or when not to use, though the sibling names make that fairly evident.

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