get_lists

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

With no annotations, the description carries the behavioral burden. It discloses that lists are account-scoped, the response includes size/list_id, the sku parameter changes each list to include contains, and that «Подборки» are intentionally not exposed. This is solid transparency for a simple read operation.

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 dense sentences with no filler. The core purpose is front-loaded, the cross-reference to consuming functions is relevant, and the «Подборки» clarification earns its place.

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?

The tool has one optional parameter, low complexity, and an output schema, so the description doesn't need to enumerate return fields. It provides the essential integration context and edge semantics for the sku parameter, making it complete for an agent to call correctly.

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 input schema already documents sku at 100% coverage. The description adds value by explaining the purpose: sku enriches each list with contains so callers can avoid duplicating a product in a list.

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 specifies the resource ('account's wishlists'), the returned fields (size, list_id, conditional contains), and explicitly distinguishes wishlists from Ozon's «Подборки». This differentiates it from related list-like sibling tools.

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?

It explains that list_id feeds set_list_membership() and delete_list(), and that passing a sku lets callers check contains to avoid double-adding a product. It also rules out «Подборки», though it doesn't directly compare against sibling tools like list_favorites.

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