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

Beyond the readOnly/idempotent annotations, the description discloses real behavioral traits: figures are preliminary, unreviewed rows are excluded from the numbers, unclassifiable transfer accounts surface as a question for the user, currency is limited to one at a time, and the agent must not round, restate or 'fix' figures. It also says the correct remedy is in the books, not the report. This is materially more than the annotations provide.

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 core output definition is front-loaded in the first sentence and the rest is operational guidance, so most sentences earn their place. Some phrasing is ornate ('said on their face') and the presentation instruction ('Say "preliminary" when you present it') runs long, costing a bit of clarity for an otherwise tight block.

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?

There is no output schema, yet the description explains what comes back (P&L plus balance sheet plus the notes on what is excluded), how it should be labeled, and what to do when figures look wrong. For a read-only report with zero required parameters, an agent has everything needed to call and present it correctly.

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 coverage is 100%, so the baseline would be 3, but the description adds meaning: it mirrors the period grammar (quarter 2026-Q1, month 2026-09, year, or from/to) and adds the constraint that only one currency at a time is handled, which clarifies when the currency parameter matters. It does not explain behavior when both period and from/to are supplied.

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 first sentence names the specific deliverables (a profit and loss for a period plus a balance sheet at its end) and states they come from the books and are marked preliminary. The phrase 'with everything they leave out said on their face' signals that the output carries notes on exclusions, which no sibling tool (gl_entries, tax_return, inv_valuation) provides. An agent can identify this as the statement-generation tool without reading the 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?

It gives concrete trigger phrasings ('how did we do this quarter', 'generate preliminary Q1 financials', 'a number for the accountant before the close') and the accepted period formats, which is strong context. It does not name an alternative tool or state when not to use this one (e.g., when the books aren't reviewed yet, use gl_changes instead), so it stops short of full routing guidance.

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