email_move

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state that moving is a mutation (irreversible action), whether permissions are required, what happens to the email's current folder states, or what the response looks like. The schema hints that sourceFolder is conditionally required for IMAP/iCloud, but the description doesn't surface this behavioral nuance.

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?

It is appropriately short and to the point, but the description is borderline under-specified rather than deliberately concise. Every sentence is functional, yet the minimalism leaves key details out. It reads as a minimum-viable one-liner rather than a carefully crafted concise description.

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 mutation tool with no annotations and no output schema, the description needs to carry more weight. With 4 parameters, 75% undocumented, and no return/lifecycle guidance, the description is inadequate. The conditional sourceFolder requirement and IMAP/iCloud special case are the only useful context, and it comes from the schema rather than the description.

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 25%, so the description must compensate, but it adds nothing about the four parameters. It doesn't explain the role of accountId, emailId, or targetFolder beyond their names. The sourceFolder's conditional requirement (IMAP/iCloud quirk) exists only in the schema, which is helpful but alone insufficient given 75% of params lack descriptions.

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 'Move an email to a different folder' has a specific verb+resource (move email) and is functional but terse. It does not mention the accountId or emailId inputs explicitly, and among siblings like email_batch_move, email_transfer, and email_delete the differentiation is only implicit — the description doesn't clarify how email_move differs from email_batch_move (single vs batch).

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?

There is no guidance on when to use this tool versus email_batch_move, email_transfer, or email_folder_create. No context is given about prerequisites (e.g., needing email_list_folders first), nor when NOT to use it (e.g., use batch for multiple emails). The description is silent on all usage guidance.

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