Get related Ozon products

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

The annotations already cover read-only, idempotent, and open-world hints, and the description adds useful behavioral context beyond those: the data comes from the product page's cross-sell block and is returned in the same format as ozon_search. This is meaningful disclosure for a read-only tool, though it does not describe pagination or error behavior.

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?

Three sentences, each earning its place: what the block is, when to use it, and what format the response follows. The description is front-loaded with the core concept and has no filler.

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 tool with no output schema and 5 parameters, the description gives the key use case and return-format hint, but it does not clarify which parameter is semantically required — required parameters are marked as 0, yet the tool clearly needs a product identifier. There is also no information about how 'same format as ozon_search' resolves if the agent is unfamiliar with that tool. This leaves meaningful gaps for an agent invoking the 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 description coverage is 60%, so the schema already documents product, rich, and compact. The description adds little parameter-level meaning: it implies the 'product' identifier is central ('with this product') and references the ozon_search return format, but it does not clarify the relationship between 'sku' and 'product', nor explain 'limit' or default behavior. This is adequate but not exceptional.

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 and resource: it returns the cross-sell block from a product page, covering 'Покупают вместе', accessories, and similar items. It also specifies the return format (same as ozon_search), which helps distinguish it from product details, offers, and variants. This makes the tool's purpose immediately clear to an agent.

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 clearly says 'Use when user asks what to buy with this product or wants alternatives,' which is explicit when-to-use guidance. It does not mention when not to use it or name alternative tools for specific cases, but the usage context is specific enough for most agent decisions.

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