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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description rightly spends its budget on behavior the annotations cannot express: the classification rules that map income to turnover, expenses to operating costs, and owner top-ups away from sales. It does not state how unrecognised category codes are handled, which is the main remaining gap.

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 sentences, front-loaded with the verb and outcome before the rule detail, and the closing sentence handles input provenance. The colon-separated clause list of rules is dense but each clause carries distinct accounting meaning, so little is wasted.

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, return values need not be explained, and the description covers the input contract and the classification semantics well for a single-parameter tool. It leaves open error behavior for unmapped or missing category codes, which for a rule-applying transform is a modest omission.

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 the schema already documents the sign convention, major-unit requirement, and per-category-code shape. The description largely restates 'signed major units per category code'; its only added value is pointing to categorise_transactions as the source of codes, which merits baseline 3 rather than higher.

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 and resource ('turn categorised bank-statement totals into balance sheet figures') and immediately distinguishes the transformation from sibling framing by naming the upstream tool categorise_transactions. Its role is separable from dormant_figures, explain_accounts, and get_prior_year_figures without opening any 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 identifies the correct upstream step ('get codes from categorise_transactions'), which tells the agent when this tool applies in the workflow. It stops short of explicit when-not-to-use guidance or naming alternatives such as dormant_figures for non-trading periods.

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