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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description is not the sole source of the safety profile. It still adds real value beyond them by disclosing that the output is an interactive chart plus table in the chat and that non-read operations are refused, a constraint the annotations do not express. It stops short of describing failure modes or how the chart responds to parameters.

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 dense sentences, front-loaded with the outcome before the mechanism, and the enumerated examples earn their place by showing valid operation_id formats. The parenthetical example list is long but functional. Minor waste in restating read-only after the annotations already do so.

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 7-parameter tool with nested objects, no output schema, and 0% schema description coverage, the description covers the primary calling convention but leaves the aggregation parameter unexplained and says nothing about what the rendered chart contains. An agent could invoke it correctly for simple cases but would be guessing on summarize and path_params.

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 carries the full burden, and it meaningfully explains two parameters: operation_id (with concrete prefixed examples such as more:kassaprognos) and query_params (same parameters as the underlying operation). The other five parameters, notably the nested summarize object with group_by/sum/all_pages that controls aggregation, go entirely undocumented in both schema and prose.

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 concrete verb and outcome: render a report or list as an interactive chart and table in the chat, with example categories (trends, rankings, ageing, forecasts). It also clarifies the mechanism (you pass an operation_id of a report/list this connection offers), which distinguishes it from plain data-fetching siblings like get_top_customers or get_receivables_aging. Slightly short of 5 because it never explicitly contrasts itself with those direct-fetch siblings.

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?

Provides contextual cues (trends, rankings, ageing, forecasts) and a hard constraint that only read operations are accepted, which is useful selection guidance. However, it never says when to prefer this over calling the underlying report tool directly, which is the central routing decision given the large sibling list. Usage is implied rather than stated.

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