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 that the figures are currency-partitioned and scope the buckets, but says nothing about period boundaries, whether 'paid this month' is calendar or rolling, or workspace-wide scope (no params implies everything). 'Free' is unexplained – it may mean no credit cost or unpaid invoices.

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?

A single tight sentence with the key breakdown front-loaded, followed by a two-word tail. The trailing 'Free.' is cryptic and slightly wasteful without explanation, but nothing else is 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 params and no output schema, the description must hint at the returned shape, and enumerating outstanding/overdue/paid/open quotes largely does that. Missing only a note on currency axis versus totals and on period definition; other invoice tools are left unmentioned.

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?

Zero parameters, so there is nothing to disambiguate; the baseline applies. The description correctly signals a no-input, whole-account aggregate rather than implying filters exist.

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 verb-less but specific scope: receivables broken down per currency into outstanding, overdue, paid-this-month, plus open quotes. That is more informative than the title and distinguishes it from detail-oriented siblings like invoices_list and invoices_get. It does not explicitly contrast with invoices_report or invoices_statement, which cover overlapping ground.

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?

No when-to-use or when-not-to-use guidance, and no mention of the obvious alternatives (invoices_report, invoices_statement, invoices_list_credits) that could return overlapping figures. The agent must infer from the word 'summary' that this is the aggregate-first choice.

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