save_mail_draft

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

With no annotations, the description carries the burden and does disclose the key behavioral trait — the draft is never sent (non-destructive, non-delivering) — plus the mode-dependent recipient rules that would otherwise cause errors. It does not cover whether drafts persist/overwrite or whether permissions are needed, but the safety profile is clear and an output schema exists for returns.

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?

Front-loaded with purpose and the never-sends constraint, then a dense block of conditional parameter rules; no filler sentences. It is slightly terse/run-on across four sentences but every clause carries actionable information.

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 9-parameter, mode-conditional mutation tool with zero annotations, the description covers the critical selection logic and the safety boundary, and an output schema handles return values. It falls short on the auxiliary parameters (attachments, cc/bcc, lookback_days), which an agent may need to guess about.

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 compensate, and it does for the hardest part: mode-conditional requiredness of subject/to_queries/source_message_ref and the recipient restrictions on reply/reply_all/forward. However cc_queries, bcc_queries, attachments, and lookback_days get no mention, leaving roughly half the parameters undocumented anywhere.

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+resource ('新建...邮件草稿' = create mail drafts) across four named modes and immediately bounds scope with '绝不发送' (never sends), which cleanly separates it from any send action. It also names the sibling edit_mail_draft as the follow-up path.

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?

Gives explicit per-mode routing: compose requires subject/to_queries, other modes require source_message_ref, reply/reply_all take no recipients, forward requires to_queries. It also states the follow-up condition for edit_mail_draft, so an agent knows both when to pick this tool and what to do next.

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