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

Annotations already cover read-only, non-destructive and non-idempotent, so the description's job is to add what they cannot. It does: month-end clamping rules ('31 Jan + 1 month = 28/29 Feb'), the negative-number subtract semantics, and commercial constraints (per-call price, first 25 free, failed calls free, repeats billed). That is real behavioral value beyond the annotations, with only the return value left unstated.

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 core operation is front-loaded, and the clamping rule plus example earn their space. However, the trailing billing block (per-call price, card key path, free tier, and the redundant 'each call is charged, so repeats are not free') consumes roughly a third of the text with overlapping statements.

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 orient the caller on result shape and it partially does via the ISO example inputs; safety profile is covered by annotations and economics by the billing text. The missing pieces are modest: it never says what the response looks like (formatted date vs timestamp) or how mixed positive/negative unit combinations are applied.

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 description coverage is 100%, which sets a baseline of 3. The description adds useful semantics (negative values subtract, month-end clamping, a concrete example), but it also advertises 'years, months, weeks, days, hours and minutes' when the schema only defines date, days, months and businessDays — an agent could reasonably attempt unsupported fields like hours or years. The mismatch outweighs the marginal additions.

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 a specific verb and resource ('add ... to a date') with concrete scope: negative values subtract, weekends are skipped for businessDays, and month-end clamping is defined. It is clearly distinguishable from date_diff and date_info, though it never names those siblings. The enumerated units (years/weeks/hours/minutes) overshoot what the schema actually accepts, which slightly blurs the stated 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?

'Use to compute due dates and expiries' gives a clear use context, and the worked example shows the call shape. There is no statement of when NOT to use it or that date_diff is the alternative for measuring the gap between two dates. Usage is implied rather than routed.

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