Таблица

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is clear. The description adds the specific HTTP GET endpoint and a documentation link, which are useful behavioral details. However, it does not describe pagination, sampling behavior, or error conditions, but these are not essential given the rich schema and annotations.

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 relatively short, but it contains redundancy: 'Таблица.' repeats the titlecars, and 'Возвращает результат в виде таблицы' restates the previous point. The useful endpoint and documentation links are included. It is not overly long, but not every sentence 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 description is too generic for a tool with 10 siblings. It does not explain what makes this endpoint distinct (e.g., plain data without drilldown/pivot/comparison aggregations) or when a caller would prefer it. The missing output schema is not a major issue, but the lack of sibling differentiation leaves the description incomplete for correct selection.

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 100%, with all 19 parameters documented in the input schema. The description itself does not mention any parameters, so it adds no semantics beyond the schema. Baseline 3 is appropriate.

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 that the tool provides access to Yandex Metrika statistical data, including report data, and returns a table. However, this is extremely broad and does not distinguish it from siblings like metrika_stat_drilldown or metrika_stat_pivot, which also provide statistical data. The title 'Таблица' adds little specificity, and the phrase 'returns the result as a table' is true of all stat 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?

The description gives no guidance on when to use this tool versus its siblings. It does not mention alternatives, exclusions, or typical use cases. An agent would not be able to decide between metrika_stat_data and the other stat_* tools based on this text alone.

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