Skapa utkast

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

Annotations cover only the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description goes well beyond that: it discloses that nothing is sent, that validation/encoding/Message-ID/sender behavior is identical to send_email, that a bridge is required, that bcc persists visibly in the draft, and what happens on failure (ValueError, nothing saved; null uid with a 'note'). That is unusually rich behavioral context.

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 the one-line purpose, then structured into narrative, Args, Returns and Raises sections that are easy to scan. Each block earns its place given the 0% schema coverage and absent output schema, though the prose between the purpose line and the Args list is somewhat long and could be tightened.

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?

A seven-parameter write tool with no schema descriptions and no output schema gets everything it needs: documented arguments, an explicit return shape ({uid, mailbox, message_id}) including the null-uid fallback, and declared error conditions. Nothing required to call it correctly is missing.

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 carries the full burden and does document all seven parameters, including which are optional (body_html, cc, bcc, reply_to) and that to/cc/bcc accept a string or a list. The per-parameter glosses are terse ('Ämnesrad', 'Brödtext i klartext') rather than adding format or constraint detail beyond type and optionality, so it compensates adequately but not exhaustively.

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 ('Skapa ett utkast i Drafts i stället för att skicka') and pins down the scope with 'Ingenting skickas'. It explicitly distinguishes itself from send_email (the pattern it mirrors) and points to send_draft and update_draft as downstream siblings, so an agent can tell it apart from every other write tool in the list.

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 the core when-to-use condition ('i stället för att skicka'), the intended review-then-send workflow ('skicka härifrån med send_draft när det är godkänt'), and routes listing of existing drafts to list_emails(mailbox="Drafts"). Alternatives and the condition that selects them are named rather than implied.

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