Skicka utkast

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

Annotations already flag destructive/non-idempotent/open-world, but the description goes well beyond them: Bcc header stripping, Bridge placing the mail in Sent, the conditions that cause a refusal with nothing sent, who removes the draft (Bridge vs. this tool), and that a partial delivery still delivered to the accepted recipients.

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?

Long, but front-loaded with the core action and organized into behavior, refusal conditions, deletion semantics, Args, Returns and Raises. The Returns and Raises detail is load-bearing since there is no output schema; a few sentences (e.g. the Bridge internalid aside) are dense but still earn their place.

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?

With no output schema, the description supplies the return shape (sent, message_id, recipients, draft_deleted, plus note/warning) and the failure modes (ValueError, SMTPPartialDeliveryError) with what each implies for retry. An agent has everything needed to call and interpret it safely.

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?

With 0% schema description coverage the description must carry the parameter meaning, and it does: uid is explained as the Drafts UID sourced from create_draft or list_emails, and mailbox is explained as always "Drafts" for confirmation. Only the exact UID format is left implicit.

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 with its full lifecycle: sends a Drafts draft exactly as it stands and then removes it. This is clearly distinguishable from send_email (composes and sends), create_draft and update_draft (which it references for the address-rewrite 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?

Explicitly says to use it only once the draft is reviewed and approved, names update_draft for fixing ambiguous addresses, and points to list_emails(mailbox="Drafts") for finding drafts. It also gives an exclusion: after a partial delivery, do not resend to everyone.

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