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

Annotations already declare destructive/idempotent/openWorld, but the description adds substantive behavior the annotations cannot express: the delete is soft rather than permanent, teammate primary emails are rejected with 422, and managed-directory workspaces conflict with 409. These are exactly the side effects and auth/ownership constraints an agent needs before invoking 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?

Three short sentences, front-loaded with the action and its soft-delete nature, followed by two error-condition clauses. No filler, no restatement of the title, and each sentence carries distinct operational information.

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 destructive two-parameter tool with an output schema and rich annotations, this covers action, semantics, and the two most likely failure modes. It omits whether the soft-deleted alias can be restored or what happens to signature installations referencing it, which is the only meaningful remaining gap.

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 100% — the `id` parameter is already documented as "the UUID returned by list_emails" and `context` is fully specified. The description's "by UUID" adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 precise verb+resource ("Delete an alias email by UUID") and immediately narrows scope with "(soft delete)", which separates it from sibling delete_* tools operating on assets, folders, signatures, smart fields, and teammates. The qualifier "alias email" also distinguishes it from delete_teammate and update_email.

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?

Gives concrete preconditions and failure conditions: primary emails return 422, and workspaces using a directory integration return 409. That tells the agent when the call is invalid, but it never names the alternative action for those cases (e.g., remove/update the address instead of deleting), so it stops just short of explicit when-not guidance.

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