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

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is partly covered. The description adds real value beyond that: it guarantees nothing is sent, identifies send_campaign as the required follow-up, and documents the plain-text markup convention for `text`.

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 with the most consequential fact ('Creates a DRAFT. Nothing is sent') front-loaded, followed by the required next step and the content-format rule. No sentence is filler.

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 output schema, the description still orients the agent on lifecycle (draft, then send) and content format. It omits anything about the returned result (e.g., a campaign identifier needed for the subsequent send_campaign call), which is the main 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 coverage is 100%, so the baseline is 3, but the description goes further by explaining the markup semantics of `text` (blank line separates paragraphs, leading '#' makes a heading) — syntax the schema does not capture. The other five parameters are left to their schema descriptions.

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 opening sentence gives a precise verb+resource ('Creates a DRAFT') and immediately scopes it against the sending action, distinguishing it from send_campaign. An agent can tell this is the authoring step, not the delivery step, without inspecting either 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?

It clearly states the follow-on action ('you then need to call send_campaign, or send it from the Mailcheer workspace') and adds a review prerequisite. It does not, however, address when to use this versus update_campaign for editing an existing draft, so the routing is strong but not exhaustive.

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