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

The description adds substantial behavioral context beyond the annotations: the email goes to a third party and cannot be recalled, the wording cannot be changed, the reminder is recorded in email history, and account or invoice reminder switches do not block this tool. These details are consistent with the destructive and open-world annotations.

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?

The description is long but front-loaded and dense with decision-relevant information. Every sentence earns its place by covering purpose, constraints, tier behavior, settings caveats, and history recording.

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?

Given the destructive external-email action, absence of an output schema, and the two-parameter schema, the description is complete enough for correct invocation. It covers failure modes, tier semantics, side effects, and where to verify prior reminders.

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?

Although schema coverage is already 100%, the description meaningfully expands parameter semantics. It explains that omitting tier auto-selects the currently due automatic tier and fails if none is due, while providing a tier sends that tier regardless of day thresholds and fails if already sent.

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 uses a specific verb and resource: it emails a payment reminder with the invoice PDF attached to the invoice's stored recipient email. It clearly distinguishes the action from sibling tools like send_invoice and get_email_history by focusing on chasing an unpaid invoice.

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 states when to use the tool (to chase an unpaid invoice) and provides explicit when-not conditions, including unpaid status, finalization, credit note status, due date, recipient email, and duplicate reminder refusal. It also points to get_email_history for checking reminders already sent.

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