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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety behavior is covered. The description usefully adds that memos/purchase commitments and exceptions are folded into the report and that the period must already exist, but it doesn't say what happens if the requested period was never built or what the output shape is.

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?

Output scope is front-loaded in the first sentence, which is good. The second sentence is marred by the garbled "Pro;" token and a compressed sibling pointer that costs clarity without saving much space.

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 read-only, three-parameter report with no output schema, the description does the important work of enumerating the returned figures. It still leaves gaps an agent would care about: the failure mode for an unbuilt period, how multi-currency periods are presented, and the meaning of "exceptions".

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 from/to formatting and the multi-currency rule are already fully documented in the schema. The description reinforces the period concept ("built period", "the period's exceptions") but adds no syntax, defaults or constraint meaning beyond what the schema provides, so the baseline of 3 applies.

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 verb+resource is specific: it reports a period account by account and enumerates the outputs (debits, credits, movement, closing balance, purchase-commitment memos, exceptions), which clearly separates it from ledger_lines. The dangling fragment "Pro;" is confusing and slightly muddies an otherwise precise statement of purpose.

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?

"a built period" implies a prerequisite (the period must have been built, presumably via ledger_build), and "ledger_lines gives the lines free" points at the alternative for line-level detail. However, neither is stated as an explicit rule — there is no "use this when / don't use this when" and no mention of what to do if the period is not yet built.

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