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

Annotations only say it is non-read-only, non-destructive, and idempotent; the description adds what those hints cannot: revert semantics tied to collateralization, an ownership precondition, the max_uint256 restriction, and on-chain version auto-detection with an override. This is exactly the extra behavioral context a caller needs before building a transaction.

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?

Four sentences, each carrying distinct information: purpose, authorization, revert condition, amount constraint, and version handling. The primary action is front-loaded and nothing is redundant with the title or annotations.

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 an output schema present, return values need no explanation, and the description covers the risky edge cases (debt/undercollateralization, owner-only, exact amounts). The one gap is that it never says the output is unsigned and requires a separate submission step, which matters for a 7-parameter transaction-building 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 coverage is 100%, so the baseline is 3, and the description adds meaningful guidance on top: amounts must be exact values from read_account_info rather than sentinel max values, and account_version is normally auto-detected. It does not clarify the asset_ids/asset_types pairing or chain_id choices, which remain schema-only.

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 concrete verb and resource: build an unsigned transaction to withdraw assets from an Arcadia account to the owner's wallet. That scope cleanly separates it from siblings like write_account_deposit, write_account_borrow, and write_account_repay without needing to open 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?

Gives real eligibility conditions (only the account owner can withdraw) and a failure condition (reverts if the account has debt and the withdrawal would leave it undercollateralized), plus a concrete directive to source exact amounts from read_account_info instead of max_uint256. It stops short of naming alternatives or noting that the produced transaction must then be submitted via a send path such as dev_send.

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