move_messages

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

No annotations are provided, so the description carries the full disclosure burden, and it mostly does not. It never states that messages are removed from the source folder (the defining mutation semantics), whether the operation is atomic across up to 100 UIDs, whether the move is reversible, or what happens to message UIDs at the destination. The only behavioral detail offered – that no delete tool exists – describes the toolset, not this tool.

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?

Two short sentences with the action front-loaded and the notable toolset constraint appended. The second sentence is meta-context rather than tool-specific, but it is short enough and useful enough for agent routing that it earns its place; nothing is padded.

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 mutating tool with three parameters, no annotations, and no output schema, the description is thin. An agent cannot determine from it whether `folder` identifies the source, whether partial failures are possible across 100 UIDs, or how success is confirmed, all of which matter for a destructive-adjacent move operation.

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 coverage is only 33%: `uids` and `destination` have no schema descriptions at all. The description mentions a destination folder conceptually but never clarifies the critical ambiguity between `folder` (which defaults to INBOX) and `destination` – i.e. which is the source and which is the target. That is exactly the kind of parameter meaning the description should supply, and it does not.

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 and resource ("Move messages to another folder") and gives a concrete example (Archive), so the core action is unambiguous. It also rules out a delete tool, which separates it from the collection's write operations. It stops short of a 5 because it never distinguishes the move operation from siblings like mark_read or list_folders in terms of when each applies.

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 deliberately no delete tool" implicitly routes the agent to this tool for removal-style workflows, which is genuine usage guidance, and "for example Archive" sketches a typical case. But there is no explicit when-to-use/when-not framing and no prerequisite context (e.g. whether the destination folder must already exist), leaving the agent to infer the intended workflow.

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