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

Beyond annotations, the description discloses important behavior: the campaign is created as a draft, nothing is sent until manually started, recipient confirmation is required, variable placeholders are substituted per recipient, scheduling is interpreted after start, and an unsubscribe link is automatically added. These details materially help an agent understand side effects and prerequisites.

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 description is front-loaded with the core draft-creation behavior and then organized around account, body, scheduling, and unsubscribe semantics. It is appropriately sized for an eight-parameter tool, though some sentences are dense and could be slightly tighter.

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 and eight parameters, the description provides the needed context: it mentions the returned id and uuid, the draft lifecycle, account prerequisites, body/content requirements, variable replacement, scheduling behavior, and unsubscribe handling. This is sufficient for an agent to invoke the tool correctly without additional schema descriptions.

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 0%, so the description must carry parameter meaning. It explains email_account_id/uuid as the sending account with a connected-mail-zone requirement, covers HTML/text body options, describes {variable} substitution in subject and bodies, explains schedule datetime in ISO 8601 with empty meaning immediate send, and notes the unsubscribe label. It leaves email_campaign_title mostly implicit, but the required title is self-evident from its name.

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 verb and resource: 'Creates a DRAFT e-mail campaign', and immediately clarifies that it returns an id and uuid. It also distinguishes the action from sending by explaining that nothing is sent until the campaign is started in the panel, which makes it clear this is a draft-creation tool rather than a send tool.

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 gives clear usage context: the sending account must be active and in a connected mail zone, and the merchant must confirm recipient consent before the campaign is started. It does not explicitly compare against siblings such as edit_email_campaign or send_email, so it stops short of full when-to-use/when-not-to-use guidance.

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