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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description is consistent with a safe read. It adds genuine behavioral context beyond annotations: the two fixed aggregation windows (7 and 30 days), the row semantics (a step row with empty button means steps reached), and the numbering convention tied to chatbot.show. It does not discuss freshness/latency of the statistics, so not a 5.

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?

Two compact sentences, front-loaded with the purpose and time windows, followed by the result-structure caveat. Every clause carries information; the parenthetical 'button пустая' is terse but functional rather than redundant.

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?

With no output schema, the description must convey what comes back — and it does: per-step reach counts and per-button press counts across two time windows, plus how to map numbers back via chatbot.show. Missing only minor details such as whether both windows are always returned together or any ordering/size of the result.

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% and both parameters are documented with provenance ('from chatbots.list'), so the schema carries the parameter burden and baseline 3 applies. The description adds no further constraint on botId or scenarioId beyond noting that step/button ids align with chatbot.show.

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?

States a specific verb+resource: statistics for a chatbot scenario over 7- and 30-day windows, broken down per step and per button. It also disambiguates the result structure ('button пустая' = step reached) and points to chatbot.show as the reference for step/button numbering, so an agent can tell it apart from the raw scenario document. It does not explicitly contrast with channel_stats, which keeps it from a 5.

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?

Usage is implied — measure funnel progression through scenario steps and button presses — and the reference to chatbot.show tells the agent how to interpret the returned numbers. There is no explicit when-not guidance and no mention of channel_stats as the alternative for channel-level metrics, so routing rests on inference.

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