export_email

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this writes a file but is non-destructive. The description adds genuinely useful context (the file lands in the local sandbox directory, and the filename defaults), but it never explains the non-idempotent behavior, e.g. what happens if the target file already exists or whether an existing file is overwritten.

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 single lead sentence is front-loaded with purpose, format, and destination, followed by a compact Args list for the three parameters. No filler or repetition; only the arg restatement of types is mildly redundant.

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?

An output schema exists, so return values need no explanation, and the description covers purpose, destination, and all three parameters. The remaining gap is overwrite/collision behavior for a non-idempotent write, which is a minor omission for this tool's complexity.

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 largely does: it defines message_id as the Message-ID, folder as the containing folder, and filename as optional with a stated default (Message-ID plus .eml) that goes beyond the schema's bare default of null. The folder default of INBOX is left to the schema, so it is not fully exhaustive.

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 verb (export), resource (a full message), output format (.eml), and destination (the local sandbox directory), which clearly separates it from read_email and save_attachment. It does not explicitly name a sibling or contrast itself with them, so it stops short of a 5.

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?

Usage is only implied: an agent can infer this is for materializing a raw .eml file locally rather than reading content in-context. There is no explicit when-to-use statement, no condition for choosing it over read_email or save_attachment, and no exclusions.

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