ozon_get_prices_v4

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

No annotations are present, so the description must carry the behavioral disclosure burden. It only states that prices are fetched and that purchase_price/cost is included; it does not mention response format, pagination, rate limits, side effects, or any other operational behavior. The read-only nature is only inferable from the tool's name.

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 very brief and front-loads the core purpose. The Russian parenthetical partially duplicates the English text, adding minor redundancy, but overall the description remains efficient and scannable.

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?

This is a simple tool with no required parameters, and the schema already documents view and offer_id. However, there is no output schema and the description does not describe the response shape beyond purchase_price/cost, nor does it clarify pagination or the difference from the plain ozon_get_prices sibling. The description is adequate for basic invocation but leaves 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 67%, with view and offer_id already documented and limit lacking description. The tool description adds no parameter-level meaning beyond mentioning that costs are included in results, which relates to output rather than parameters. Baseline 3 applies because the schema covers most parameter semantics.

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 the resource as prices and adds a distinctive scope: the v4 API and the inclusion of purchase_price/cost. This separates it from the sibling ozon_get_prices and from set_price tools, though it lacks an explicit verb like 'get' or 'list' in the description text.

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 implies this tool should be used when v4 price data including purchase_price/cost is needed, which provides some usage context. However, it does not explicitly name any alternative tool or state when not to use this tool, leaving the selection rationale mostly implicit.

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