Take email away from the application

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

Beyond the `destructiveHint=true` annotation, the description discloses the concrete consequences: the token is refused, the running app keeps its existing variables, and mail fails until `email_create` restores setup. It also reveals the 409 behavior when the platform has paused the email service and states the account-token requirement, which is unusually rich behavioral context for a destructive 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?

The action and immediate consequence are front-loaded, followed by usage restriction, conflict behavior, and auth requirement. Every sentence contributes operational information, with no redundant restatement of the tool name or annotation.

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?

With no parameters and no output schema, the description supplies the context an agent needs: what is destroyed, what happens to the running app, how to restore email, when not to use it, the 409 pause condition, and the auth requirement. Nothing material is missing for correct invocation.

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 input schema has zero parameters, so there is no parameter semantics burden and the baseline is 4. The description appropriately focuses on behavioral effects and prerequisites rather than inventing parameter details.

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 destructive action on a specific resource: taking email away from an application and refusing its token from then on. It clearly distinguishes the operation from setup by noting that mail fails until `email_create` runs again, so an agent can identify the tool's role without ambiguity.

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 gives a strong use restriction: only when the user asked for it. It also explains a conflict condition (409 while the platform has it paused) and the prerequisite account token. It could be slightly stronger by explicitly pointing to `email_pause` or `email_resume` as alternatives, but the operational context is clear.

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