ozon_returns_report

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action verb and does not disclose whether the report is created asynchronously (likely, given ozon_report_list/ozon_report_info siblings), whether it mutates state, what scope it covers, or any operational caveats. 'Create' implies a resource is produced, but the consequences and lifecycle of that resource are unexplained.

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?

A single sentence with zero filler; the verb is front-loaded and the Russian parenthetical adds bilingual clarity without bloat. It is efficiently sized for the amount of information it conveys, though the brevity comes at the expense of missing behavioral and usage context.

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 no output schema and no annotations, the description must be self-sufficient for an agent to call the tool correctly, and it is not. An agent is left without the report scope (FBO/FBS/RFBS), the expected filter object structure beyond 'date_from, date_to', whether the result must be polled via a report-info tool, or what the return value is. Given the nested filter object and the existence of report-list/report-info siblings, these are material gaps.

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 description coverage is 100% — the filter property is documented as 'date_from, date_to etc.' — so the baseline is 3 regardless of description content. The description itself adds no parameter-level detail and does not even mention the filter parameter. The schema's own description is thin ('etc.'), but the coverage criterion keeps this at baseline rather than lower.

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 a specific verb ('Create') and a clear resource ('a returns report'), reinforced by the Russian gloss 'отчёт по возвратам'. It is distinguishable from the returns listing tools (ozon_returns_fbo, ozon_returns_fbs) and other report-creation tools at a basic verb+resource level. However, it does not clarify whether the report covers FBO, FBS, or RFBS returns, which leaves some ambiguity against the large sibling set.

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 no guidance on when to use this tool versus alternatives. The sibling list contains directly competing report-creation tools (ozon_report_products_create, ozon_report_stocks_create, ozon_report_finance_create) and returns tools (ozon_returns_fbo, ozon_returns_fbs, ozon_returns_fbs_get), but no alternatives, exclusions, or conditionals are mentioned.

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