Подтвердить вывод (шаг 3)

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

With no annotations provided, the description carries the full behavioral burden, and it does so strongly: it prints an ALL-CAPS warning 'ДЕНЕЖНАЯ ОПЕРАЦИЯ, НЕОБРАТИМАЯ' and states that after this call the funds leave. That is precisely the kind of critical behavioral trait an agent needs to know before invoking an irreversible money‑moving operation.

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?

Three short, information-dense sentences. The critical irreversible warning is front-loaded with all-caps, then the required parameters are given, and the fiat/crypto distinction completes the guidance. There is no fluff or redundancy.

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 4-parameter tool with no output schema and no annotations, the description covers the essential usage context: it must be invoked only when a confirmation code and credentialTokenId are at hand, and it warns about the irreversible money movement. It relies on the title's 'step 3' to link the flow and on the schema for exact parameter names, but overall the agent can correctly decide to call this tool and prepare the payload with confidence.

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 input schema already describes every parameter at 100% coverage, including the fact that orderId is required for fiat. The description repeats the same information ('Нужны код подтверждения и credentialTokenId', 'для фиата дополнительно передаётся orderId, для крипты — нет') without adding new meaning beyond what the schema states. Since schema coverage is complete, the baseline of 3 applies, and the description provides minimal extra parameter-level value.

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 identifies the operation as the withdrawal confirmation step (step 3) with a specific verb 'Подтвердить вывод', and explicitly states the irreversible, money-moving nature of the call. This distinguishes it from nearby tools like wata_wallet_withdraw_initiate (which starts the flow) or wata_wallet_withdrawal_limits, 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 gives clear context for use: it requires a confirmation code and a credentialTokenId from the request, and specifies that a fiat withdrawal additionally needs an orderId while crypto does not. It does not name an alternative or say 'use only when …' explicitly, but the reference to the prior request and the conditional parameter guidance shape when the agent should invoke it. A slightly more explicit reference to 'after you have created the withdrawal request' would raise this to a 5.

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