ozon_product_description

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 states only that the tool relates to a product description by offer_id; it does not disclose whether the operation is read-only, what the response looks like, error behavior for invalid offer_ids, or any rate limits. For a tool with zero annotation coverage, this is a significant gap.

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 brief and front-loaded with the key information, but the parenthetical Russian translation ('описание товара') is redundant and earns no place. While concise, it is closer to under-specification than to tight, deliberate writing.

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, no annotations, and no parameter descriptions, the one-line description carries the entire burden of completeness. It provides the core purpose but omits output format, usage context, and differentiation from the many sibling product tools, so an agent cannot confidently invoke it blind.

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 0%, so the description must compensate. It does identify offer_id as the lookup key ('by offer_id'), which is minimal useful semantics, but it does not explain the expected format of offer_id, whether it is a numeric seller-side ID, or how to obtain it. The compensation is insufficient for 0% coverage.

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 resource (product description) and the lookup key (offer_id), so an agent can tell this tool fetches a product's description. However, it lacks an explicit verb like 'get' or 'retrieve' and does not differentiate itself from siblings such as ozon_product_info or ozon_product_attributes, which likely return overlapping data.

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?

There is no guidance on when to use this tool versus the many other product-related siblings (ozon_product_info, ozon_product_attributes, ozon_product_list). No context, exclusions, or alternatives are mentioned, leaving the agent to guess whether this tool is preferred for description-only lookups.

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