ozon_report_products_create

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It states the basic operation but does not mention whether report generation is asynchronous, what the response contains, how to retrieve the finished report, or any side effects. 'Create' implies a mutation, but the consequences are unspecified.

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 a single front-loaded sentence with clear verb and resource and no filler. It is efficient, though it leans toward under-specification, which prevents a top score.

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?

There is no output schema and no annotations, so the description is the only source for return values, invocation semantics, and prerequisites. It omits whether the report is created synchronously or asynchronously, what the response looks like, and how the visibility parameter behaves. The low parameter count keeps the gap from being severe, but a creation tool needs more operational detail.

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 only parameter, visibility, has no schema description and the description does not explain it either. With 0% schema description coverage, the description should compensate by defining valid values and the effect on the report, but it does not even mention visibility. The Russian translation merely restates the tool's purpose rather than adding parameter meaning.

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 identifies a clear verb and resource: 'Create a products report.' The word 'products' helps distinguish this from related report-creation siblings like ozon_report_stocks_create, ozon_report_finance_create, and ozon_report_discounted_create. However, it does not explicitly contrast itself with those siblings, so it stops short of full differentiation.

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 no guidance about when to choose this tool over nearby alternatives such as ozon_report_stocks_create, ozon_report_finance_create, or ozon_report_list. The only usage cue is the implicit product scope in the name, with no exclusions or alternative-selection criteria stated.

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