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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the constraint that only custom folders qualify, which is genuinely useful beyond the annotations. However, it says nothing about whether contained messages are deleted, whether deletion is reversible, or whether system folders are rejected.

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 with no filler; the destructive action is the first word. It borders on under-specification rather than verbosity, but it wastes nothing.

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 mutation with no output schema and an undocumented parameter, the description should cover cascade behavior, reversibility, and the id's provenance. None of that is present, leaving an agent to guess about the consequences of an irreversible action.

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?

One parameter with 0% schema description coverage; 'id' could plausibly be a message id, mailbox id, or folder id given the many siblings using 'id'. The phrase 'custom folder' narrows it to a folder identifier, which is the main semantic value added. It still does not state the id format or source (e.g. from mailbox_list).

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 and resource: 'Deletes a custom folder.' The word 'custom' distinguishes it from deleting messages (mail_delete) or system folders, though it never explicitly names a sibling alternative. An agent can identify what the tool does at a glance.

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 instead of mail_delete, domain_inbox_delete, or mailbox_rename, nor any prerequisite or precondition. The only implied context is that the target must be a custom folder, which the agent has to infer from the adjective 'custom'.

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