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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: it returns a formatted table with structured data, the widget already renders it to the user, and the agent should add interpretation rather than reproduce rows — non-obvious interaction semantics not derivable from 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?

Front-loads what the tool produces, then the alternative, then scenario naming, then the return/rendering contract. Every sentence carries information, though the widget/interpretation guidance runs long and could be tightened.

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?

Behavioral context is strong — return format, widget rendering, and interpretation expectations are all covered despite there being no output schema. However, with 8 parameters and 0% schema coverage, five parameters (scale, decimals, filters, period_start, period_end) remain opaque, which is a real gap for a tool whose whole job is parameterized statement generation.

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% across 8 parameters, so the description must carry the load. It clarifies `statement` (P&L, variance, exec summary), `scenarios` (columns, with a required user-facing `alias` like Actuals/Budget/Variance), and `dimensions` (optional breakdown by period or cost centre), but says nothing about `scale`, `decimals`, `filters`, `period_start`, or `period_end` — five undocumented parameters.

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 (run) and resource (financial statement) and immediately enumerates the concrete outputs — P&L, variance report, executive summary — plus the row/column semantics of the result. An agent can distinguish this from run_metric or run_statement_data without opening a schema.

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?

Gives an explicit routing rule: for an unspecified general P&L, prefer `full_pnl` when listed by precis_orientation. It also prescribes downstream behavior (add interpretation, don't restate the table unless asked or the widget is unavailable). It does not clarify the boundary against the close sibling run_statement_data, which keeps this at 4.

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