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

With destructiveHint=true and readOnlyHint=false already declared, the description adds substantial context beyond annotations: prerequisites (Drafts enabled, Keeploop Pro), the explicit side-effect boundary ('Nothing is sent, accepted or declined'), and the save_draft=false escape hatch. It does not explain whether saving a draft can overwrite an existing one.

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?

Dense and front-loaded: the core action and its non-destructive boundary come first, with prerequisites and parameter notes following. Sentences earn their place, though the parenthetical default window is slightly compressed relative to the days/working_hours parameters it maps to.

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?

An output schema exists so return values need no explanation, and the description covers prerequisites, side effects, and the draft-only outcome. The remaining gap is the undefined relationship between mail_id and event_ref for identifying the meeting to reschedule.

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 0% across 9 parameters, so the description must carry the load. It explains intro's role, save_draft=false behavior, and implies event_ref via 'same length as the event', but start, end, mail_id, slots, days, and working_hours semantics (beyond the parenthetical default) are left 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 states a precise verb+resource ('ask for a new time for a meeting'), clarifies it does NOT touch the calendar, and describes the concrete artifact produced (a threaded reply saved to Mail's Drafts). This clearly separates it from propose_event and save_reply_draft among siblings.

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?

It gives context for when to use it (rescheduling via negotiation rather than direct calendar edits) and names get_voice_profile as the way to write the intro. It also documents the save_draft=false variant as an alternative mode. It stops short of explicitly contrasting with propose_event or stating when not to use it.

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