draft_follow_up

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

No annotations are provided, so the description carries the burden. It discloses that the tool 'generates a polite follow-up that references the original message' and that create_draft controls whether a draft is saved. However, it doesn't disclose whether it will reference thread context, how the output is returned (draft vs plain text), or any side effects beyond the optional create_draft flag.

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?

The three-sentence description is compact and front-loaded with the core purpose. Every sentence earns its place: what it does, when to use it, and what it produces. Slightly more could be packed but current length is well-balanced.

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?

The tool has 5 parameters, an output schema, and full schema coverage, which offloads much of the burden. The description covers the core scenario and output nature. It could mention the optional follow_up_id linkage more explicitly, but given the rich schema and output schema present, completeness is adequate.

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 100%, so all 5 parameters have descriptions in the schema. The description adds the key instruction that instructions parameter accepts tone/deadline hints, and notes the account uses first available. Given full schema coverage baseline is 3, the description slightly adds by clarifying the interplay and referencing get_follow_ups for the follow_up_id parameter.

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 clearly states it drafts a follow-up email for a message awaiting response, with a specific verb+resource. It differentiates from siblings like draft_email, draft_reply, and create_email_draft by focusing specifically on follow-ups to unreplied emails, though it doesn't explicitly name alternative tools for comparison.

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 description provides clear use context ('when you sent an email and haven't received a reply'). It doesn't explicitly state when NOT to use it vs alternatives like draft_reply or draft_email, but the follow-up-specific framing and connection to get_follow_ups parameter imply the domain clearly.

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