ozon_get_rate_limits

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

No annotations are provided, so the description carries the full burden. It discloses the read-only lookup behavior, the precedence behavior, and importantly warns that 'many limits in v0.2 are conservative guesses (source: 'guess')' and advises verification before production use. This is substantive behavioral context beyond the schema.

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 compact and front-loaded with the core purpose. Every sentence earns its place: the first states what the tool does, the second explains argument behavior, and the note conveys an essential reliability caveat. No redundant 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 read-only lookup tool with two optional parameters and an output schema, the description covers the main usage modes and adds an important data-quality warning. It could more explicitly define what values 'section' expects and how to discover valid section identifiers, but sibling discovery tools likely cover that gap.

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 explains operation_id's meaning and precedence behavior clearly. The 'section' parameter is implied by 'a method, section, or the whole API' but not given a dedicated explanation; still, its purpose is reasonably inferable.

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 uses a specific verb ('Look up') and clearly identifies the resource ('rate limits') and scope options ('a method, section, or the whole API'). This distinguishes it from sibling tools like ozon_describe_method or ozon_search_methods, which serve clearly different purposes.

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 concrete invocation guidance: 'Without arguments returns all known limits' and 'With operation_id, returns the most specific limit'. It explains the precedence rule per-method over per-section over global. It does not explicitly contrast with sibling tools, but the focused scope makes the usage context clear.

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