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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a small behavioral detail about draft.id not being email_id or subject, which helps prevent misuse. It does not disclose pagination or response structure, but that is partially covered by the schema's cursor description.

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?

The description is extremely concise—two sentences with no filler. The primary purpose is front-loaded, and the critical clarification about draft.id is placed immediately after, making it efficient for an agent to parse quickly.

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 simple list operation with annotations covering safety and the schema covering pagination and account selection, the description is nearly complete. It might benefit from noting the return type (a list of drafts) but that is implied by 'List'. The clarification about draft.id addresses the most likely point of confusion, so the tool is effectively usable without further context.

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 50%: cursor and account_id have descriptions, while limit and any_email do not. The description does not mention any parameters, so it adds no semantic value beyond the schema. Since the schema covers half, the baseline of 3 is appropriate, and the description does not compensate for the missing 50%.

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 clearly states the action ('List email drafts') and the resource, making it distinct from sibling tools like email_get_draft or email_list_messages. It also adds a critical clarification about the returned draft.id, which is essential for chaining with other draft operations, removing ambiguity about the ID semantics.

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 usage by stating that the returned draft.id is used for get/update/send/delete, but it does not explicitly distinguish when to use this tool versus email_list_messages or email_get_draft. There is no 'when not to use' guidance, though the context of listing drafts is clear enough for basic routing.

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