create_draft

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

Beyond the annotations (all false), the description discloses the non-sending behavior and the result echoing the recipient list, which are crucial for an email tool. It does not mention permissions or rate limits, but the provided details are valuable and do not contradict annotations.

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?

Three sentences with no redundancy, front-loaded with the primary action and immediately followed by the most important behavioral nuance (never sent). Every sentence earns its 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 partially explains the return behavior (echoes recipient list) and the post-save state. It does not cover attachment handling or errors, but given the tool's moderate complexity, the provided context is sufficient for an agent to use 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?

Schema description coverage is only 20% (attachments have a description), and the tool description adds minimal parameter meaning beyond referencing the 'recipient list.' It does not explain subject/body semantics or required parameters, leaving the burden on a sparse schema.

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 specific action ('Save a draft') and resource ('Drafts folder'), clearly differentiating this write tool from the read-only sibling tools. The verb and object are unambiguous, and the 'never sent' detail further distinguishes its purpose.

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 implies when to use the tool (creating a draft) and emphasizes it does not send emails, but it does not explicitly mention alternatives or when not to use it. The context of sibling read tools makes the distinction clear, but it stops short of explicit guidance.

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