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

Beyond the annotations (non-read-only, non-destructive, non-idempotent, closed-world), the description adds genuinely useful behavior: quiet hours are respected even for on-sale reminders, delivery rides on an existing alert's confirmed channel, and movie dates are supplied facts rather than predictions. It does not say whether repeating calls create duplicate reminders (relevant since idempotentHint=false) or what happens when the target time has already passed.

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?

Four dense sentences, front-loaded with the two modes and followed by preconditions and limits; no filler or restatement of the tool name. Slightly compressed phrasing ("an already booked planner ticket") costs a little readability but nothing is wasted.

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 an output schema and annotations present, the description needn't explain return values, and it covers prerequisites and behavioral constraints well. However, for a 7-parameter non-idempotent mutation it omits how parameters combine per kind and what happens on duplicate or past-dated reminders, which an agent needs to call it correctly.

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 0% across 7 parameters, so the description must carry the semantics, and it explains only the deliverySubscriptionId concept loosely and that "at" is a human-selected date/time. It says nothing about minutesBefore (offset semantics and 1–10080 bounds), the event enum, or that ticketId is needed for kind=ticket while movieId plus event are needed for kind=movie, leaving the conditional requirements undocumented.

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 a specific verb/resource (set a reminder) and splits it into two clearly different modes: pre-show reminders for an already booked ticket, and explicit on-sale/first-showing dates for a known movie. It also explicitly separates itself from booking, though it never names the sibling tools (create_alert, list_reminders) it should be distinguished 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?

Preconditions are stated (must reference an existing owned Following alert with confirmed email/registered push) and an exclusion is given ("Does not book or create notification consent"), which tells the agent when NOT to use it. It stops short of naming alternatives such as create_alert for consent creation, so routing 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.