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

Annotations establish write (readOnlyHint=false), external (openWorldHint=true), and non-destructive. The description adds meaningful context beyond that: live mode emails a real person from the user's mailbox and requires showing the exact email for approval first, while simulation is a true no-op. Gaps remain on idempotency/sendNow behavior.

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?

Two tight sentences, action front-loaded, and the highest-stakes detail (live emails a real person, get approval first) is stated early. No filler.

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 7-parameter mutation tool with a 0%-coverage schema and no output schema, the description covers the decisive behavioral facts (approval gate, simulation safety) but omits idempotency and sendNow semantics 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%, so the description must carry parameter meaning. It thoroughly explains the mode enum (live vs simulation) and hints at the followUps cap ('up to two follow-ups'), but leaves sendNow, idempotencyKey, projectId, siteId and threadId unexplained.

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 ('Schedule a drafted thread') and adds scope ('up to two follow-ups'), so the agent knows this schedules an existing thread rather than creating one. It does not explicitly differentiate from close siblings like schedule_outreach_batch or send_outreach_follow_up, so a 4 rather than a 5.

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?

Explains the mode=live vs mode=simulation choice and adds an approval workflow step for live sends, which is real usage context. However, it never says when to pick this tool over schedule_outreach_batch, send_outreach_follow_up, or stop_outreach_sequence, leaving selection to inference.

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