report_aged_receivables

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

No annotations are supplied, so the description carries the full behavioral burden, yet it only implies read-only behavior by calling itself a 'report'. It says nothing about required permissions, result size or row limits, pagination, or what the response contains. The one informational addition, the report_date convention, is a parameter note rather than behavioral disclosure.

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, no filler, with purpose stated first and the non-obvious parameter convention second. Nothing is redundant or padded.

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 should at minimum clarify the summary-vs-detail boundary against report_aged_receivable_detail and ideally mention how aging_method/aging_period interact. The rich nested parameter schema covers the input side well, so the gaps are moderate rather than severe, but they sit exactly where an agent is most likely to choose the wrong report.

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?

The nested schema documents every sub-parameter in detail, so the baseline would be 3, but the description adds something the schema does not contain: the explicit warning that this report uses report_date rather than start_date/end_date. That actively prevents a plausible wrong invocation for a report tool in a family that likely uses date ranges elsewhere.

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 description gives a specific verb and resource ('Run an Accounts Receivable Aging Summary report') plus a clear statement of what the output contains ('outstanding customer balances grouped by aging period'). The word 'Summary' implicitly separates it from report_aged_receivable_detail, but that sibling is never named, so differentiation is left to inference.

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 only implied: an agent can infer it should call this when it wants an aging summary rather than individual outstanding transactions. There is no explicit when-to-use statement, no mention of report_aged_receivable_detail as the alternative for per-invoice detail, and no prerequisites or exclusions.

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