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

Beyond annotations (which only say non-read-only, open-world, non-destructive), it discloses the actual side effects — personal links are minted, a first email plus a series of Nudges on the practice's nudge plan are sent — and describes the dry-run preview in concrete terms (who would be chased, who has no email, checklist, send-by date, HMRC deadline). It also explains the repeat-safety semantics ('Clients already being chased are left alone'), which usefully qualifies the idempotentHint=false annotation by clarifying that duplicates are avoided at the client level rather than the call level.

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?

Front-loaded with the core action and then cleanly sectioned with 'Use this when' and 'Not for' labels; nearly every sentence carries information. The opening sentence is long and packs the email/Nudge sequencing into one breath, and the parenthetical explaining the two preview dates is slightly dense, costing a point.

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?

Rich enough for a mutating, open-world tool with no output schema: it covers side effects, the dry-run preview, the default quarter, and repeat-safety. It stops short of saying what confirm:true returns (job id, counts) or how the existing nudge plan affects timing, which an agent inspecting results might want.

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 already 100%, so the baseline is 3; the description earns above that by adding meaning to `confirm` beyond the schema's generic 'shows what would happen' — it names the four things the preview returns. The targeting and checklist parameters and the default quarter are covered, though the idempotency_key parameter is left to the schema.

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 states a specific verb and resource ('Starts chasing Clients for their records for a Quarter') and goes on to name the exact mechanics: a personal no-login link, a first email, then Nudges on the practice's plan. It is clearly distinguishable from the closest sibling, send_nudges_now, which is explicitly excluded.

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 has an explicit 'Use this when' block that enumerates the three targeting modes (everyone, a tag group, one Client) and the checklist variant, plus a 'Not for' block naming the alternative for reminders and the unrelated case. There is no ambiguity about when to reach for this tool versus a sibling.

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