cash_register_ledger

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the exact shape of each day bucket and the 366-day range cap, a constraint not expressed in the schema. It stops short of saying what happens for days with no activity.

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?

Three tight sentences, front-loaded with the primary purpose, then return shape, then the constraint. No filler; each sentence carries a distinct fact.

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, the description must explain returns, and it does so at the bucket level. It also discloses the range limit and the zero-required-params defaults. The remaining gap is how this differs from the sibling cash-register read tools, which matters in a family this dense.

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%, including defaults for 'from' and 'to' and the companyId override, so the baseline is 3. The description only refers generically to 'the requested date range' and adds no format or boundary semantics beyond the 366-day cap already counted under behavior.

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?

Concrete verb+resource: returns a daily cash ledger over a date range, and it enumerates exactly what each day bucket contains (opening balance, entries, totals, closing balance). It never names the sibling tools that retrieve similar data (cash_register_balance, cash_register_movements_list), so the agent must infer the distinction itself.

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?

Usage is implied by 'daily cash ledger across the requested date range', which suggests periodic reconciliation over a span rather than a point balance. However, no when-to-use/when-not and no alternatives are offered, leaving the agent to guess whether to call this or cash_register_movements_list for transaction-level data.

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