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

The description discloses a confirmation step ('Confirm (yes/no) before executing') and notes that the account currency is used for payout. With no annotations, it carries the full burden, but it omits important details such as irreversibility, potential fees, or failure modes, which are critical for a money withdrawal 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?

The description starts with a clear one-line summary but then repeats the exact same sentence immediately, wasting space. The rest is organized with @param block and useful context, but the duplication undermines conciseness.

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 description covers prerequisites, parameter meanings, and notes the return type. However, for a financial operation with no annotations, it lacks detail about safety, error handling, or the nature of the confirmation step. Since an output schema exists, missing return details are acceptable, but the overall context is only partially 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 description includes @param explanations for all six parameters, adding meaning beyond the bare input schema. It explicitly clarifies account_fk is a database ID (int) not an address and may not be 0, and directs users to /wallet/rba_list to find rba_fk, which is essential for correct invocation.

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 'Withdraws' with a clear resource 'to a bank account' and adds scope 'anywhere world-wide'. It distinguishes from sibling tools like netfluid__withdraw_to_ott by explicitly targeting bank accounts and referencing the recipient bank account (rba).

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 prerequisite: 'The recipient bank account (rba) must already be set. See /wallet/rba', and clarifies that the account currency determines payout. However, it does not explicitly discuss when to use this tool versus alternatives like withdraw_to_ott or other withdrawal methods.

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