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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds substantive domain behavior: reminders are internal-only ('send nothing to the prospect') and are independent of campaign scheduling. That prevents the agent from conflating a reminder with an outbound scheduled message. Return format and pagination remain undisclosed.

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?

Three short sentences with the definition front-loaded and zero filler. The closing clause 'the campaign schedule, which is `campaign_update`' is slightly ambiguous about whether `campaign_update` is the schedule or the tool that edits it, a minor wording cost.

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 parameter-optional, read-only list tool with full schema coverage, four annotations, and no output schema, the description supplies the essential conceptual framing. It stops short of stating what happens when both IDs are omitted (list everything vs error), which is the one behavior an agent would still have to guess.

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 two ID parameters are already fully documented with their source tools. The phrase 'on a conversation or a lead' faintly signals that the filters are alternative scopes rather than required inputs, but adds no syntax, mutual exclusivity, or default behavior beyond 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 names the resource precisely as 'follow-up reminders set on a conversation or a lead' and adds a clarifying gloss ('private nudges for your team at a point in time'), so an agent knows exactly what entity is being enumerated. The list verb itself is only carried by the name/title, and no sibling listing is contrasted, but the resource is unambiguous.

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?

The final clause routes the agent away from campaign scheduling to `campaign_update`, which is a genuine when-not signal. However, it never addresses the closest alternatives (`reminder_create`, `reminder_delete`) or says whether to call this with both, one, or neither ID, so routing is only implied.

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