wb_finance_reports_list

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

With no annotations, the description carries the behavioral burden, but it only adds 'data from 2025-01-01' and the word 'list'. It does not disclose pagination behavior, output shape, required permissions, or whether the endpoint has any side effects. 'List' implies a read operation, but beyond that the behavior is under-specified.

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, but it contains redundant or low-value fragments: '(список отчётов)' duplicates 'list', and '[P0]' is a priority marker that doesn't help tool selection. It is concise but not tightly purposeful.

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 5 parameters, no output schema, and no annotations, the description is too thin. It leaves pagination, period meaning, date_to format, response structure, and usage boundaries unexplained, so an agent cannot confidently invoke it correctly across all cases.

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 only 20%: date_from has a format hint and period/limit/offset have defaults, but their semantics are not explained. The description does not compensate; the only parameter-related detail is 'data from 2025-01-01', which hints at a constrained date range. limit, offset, period, and date_to remain effectively undocumented.

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 states this is a 'Realization reports list' and names the API version (finance-api v1). It differentiates itself from wb_finance_report_detailed by presenting itself as the list step: 'Then call wb_finance_report_detailed'. However, it doesn't explicitly distinguish wb_finance_reports_list from the sibling wb_finance_report, leaving slight ambiguity.

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 instruction 'Then call wb_finance_report_detailed' provides a sequential usage hint: this tool returns a list that should be followed by a detailed lookup. That is useful but not explicit about when to choose this tool over alternatives like wb_finance_report or wb_finance_acquiring_list, and no exclusions are given.

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