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

Beyond the annotations it discloses genuinely useful behavior: reminders run server-side with no model in the loop, a reply auto-clears a follow-up, the server restores snoozed mail at the target time, and done vs cancel differ in where the message ends up. It also rules out an expected side effect with "Nothing here sends mail." It does not flag that done/cancel are irreversible given destructiveHint=true.

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?

It opens with the defining property (survives chat close, no model in the loop) before the action breakdown, so it is front-loaded. The action sentences are dense but each carries a distinct rule; only the repeated quoted action names cost a little length.

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?

For a 10-parameter, four-mode tool with full schema coverage, annotations, and an output schema, the description covers the remaining unknowns: id provenance, per-action parameter requirements, lifecycle effects on the message, and the no-send guarantee. Nothing an agent needs to call it correctly is missing.

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 100%, so the baseline is 3, but the description adds something the flat schema cannot express: which parameters belong to which action (follow_up takes message_id plus days or due_at; snooze takes message_id, until, optional condition and folder; done/cancel take `id`). That conditional grouping is real added meaning.

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 names the resource (server-side reminders) and enumerates the four concrete operations (follow_up, snooze, done, cancel) with a one-clause definition of each. It also separates itself from the sibling reminder_list by saying that list is where due follow-ups surface and where `id` comes from.

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?

Each action carries an explicit selection rule — follow_up tracks an unanswered sent message, snooze pulls a message out of the inbox until `until`, done stops but leaves it, cancel stops and restores it now. It stops short of routing against adjacent siblings like schedule or approval_schedule, so the when-not-to-use side is only partially covered.

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