wb_return_answer

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does well by explaining what each action does—approve1 is a WB defect check, approve2 takes the item back, autorefund1 refunds without return, and rejectcustom requires a comment. It does not mention irreversibility or side effects beyond the action descriptions, but the provided semantics are meaningful.

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 compact and front-loaded with the core purpose, followed by a dense enumeration of actions. The trailing Russian phrase '(ответ на возврат)' is redundant for an English-language agent, but it does not significantly hurt clarity.

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 the key invocation details: the required action choices, their semantics, and the comment requirement. It does not explain where to obtain the claim_id or how the claim's actions[] are retrieved, but the description is sufficient for an agent that already has a claim object. The lack of output schema is not a major gap for an action-oriented 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 only 33%, so the description must compensate. It does: it defines the valid values for 'action' and their meanings, and clarifies that 'comment' is needed for rejectcustom. 'claim_id' remains implicit as the identifier of the claim, but the overall parameter guidance is substantially better than the schema alone.

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 names a specific verb ('Answer') and resource ('return claim'), and enumerates the exact actions available, making the tool's function unmistakable. It differentiates itself from sibling tools like wb_returns_list, which lists returns rather than acting on them.

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: use it to respond to a return claim, and select the action strictly from the claim's actions[]. It does not explicitly name alternative tools or state when not to use it, but the action list and 'answer a return claim' make the intended use clear.

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