wb_orders_status_history

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

No annotations exist, so the description carries the disclosure burden. It does add two useful behavioral facts: results are limited to 100 and the data is cross-border-scoped. However, it does not state whether the operation is read-only, what happens if more than 100 statuses exist, whether pagination is available, or what the response shape is.

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 short and front-loaded with the core action, which is good. However, the parenthetical '(история статусов)' merely repeats 'status history' in Russian and adds no information. The comma-fragment structure reads more like tags than a coherent sentence.

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 simple one-parameter tool the description captures essential limits (max 100, cross-border), but with no output schema it omits the return format entirely. It also fails to clarify whether input order_ids length is capped or whether max 100 applies to returned statuses. Sibling differentiation and error semantics are also absent.

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 0% description coverage, so the description was expected to explain order_ids, but it never mentions the parameter. 'Max 100' may hint at a limit, but it is not tied explicitly to the input array. Thus the description adds no parameter meaning beyond the schema's type and required flag.

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 states that the tool returns order status history and adds two boundary qualifiers: cross-border scope and max 100 entries. It lacks an explicit action verb, but 'history' plus the Russian parenthetical make the retrieval intent clear. It is distinguishable from current-status siblings like wb_orders_status because it specifies history and a result cap.

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?

No when-to-use guidance is provided; the description does not say how this differs from wb_orders_status, wb_dbs_orders_status, or wb_orders_list. The only contextual signal is 'cross-border,' but there is no explicit instruction for choosing this tool over alternatives. An agent must infer usage from the name and sibling set.

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