copy_email

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

No annotations are provided, so the description carries the full burden. It does disclose the key safety trait (source email is preserved) and scopes the operation to the Mac's Apple Mail rather than other providers, which is genuinely useful. It does not explain how the source email and destination mailbox are identified with zero parameters, nor what happens on name collisions or permission failures.

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?

A single front-loaded sentence that names the action, the resource, the host application, and the non-destructive guarantee. No filler whatsoever.

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 zero-parameter, no-output-schema tool the description is nearly complete, but the critical operational question — how the email to copy and the destination mailbox are chosen when nothing is passed in — is left entirely unstated. An agent could not confidently invoke this from the description alone.

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?

The tool takes zero parameters, so per the baseline this scores 4; there are no parameter semantics to document. The one residual concern is that with no params the description should hint at the implicit targeting mechanism (e.g., current selection in Mail.app), which it does not — but that is a completeness issue rather than a parameter one.

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?

States a specific verb (copies) and resource (an email into another mailbox) and names the target client, Apple Mail on the Mac. The clause 'the original stays where it is' implicitly distinguishes it from the sibling move_email, so an agent can differentiate the two without opening a schema.

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 non-destructive framing implies when to pick this over move_email, but it never explicitly says 'use move_email to relocate the original' or states any prerequisite (e.g., the destination mailbox must already exist). Usage is inferable rather than instructed.

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