write_sequence

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

With no annotations, the description carries the full burden and does well: it discloses that output is saved as new variants and never overwrites existing text, that an empty campaign receives the drafted steps, and that each email is validated against a content checklist with failures returned in 'problems'. It omits any statement about permissions or rate limits, but the mutation semantics and side effects are well covered.

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?

Dense but front-loaded: the core verb and mode branching come first, then side effects, then the precondition. Every sentence contributes information, though the paragraph is slightly long with the checklist and profile caveats packed into the tail.

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 six-parameter mutation tool with no annotations and no output schema, the description covers the essential ground: what is produced, that nothing is overwritten, that validation results come back as 'problems', and the prerequisite profile configuration. Only the shape of the returned variants/steps is left unspecified.

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 83%, so the enum and field descriptions already explain mode, angle, steps, persona and variantId. The description restates the mode meaning but adds no format, constraint, or interaction 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 specific verb+resource ('Write emails with AI from the offer profile') and immediately enumerates the four operating modes (sequence, rewrite, shorter, angle), so an agent knows exactly what it produces. The non-overwrite behavior also implicitly separates it from sibling tools like set_sequence that replace sequence content.

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?

Clear context for each mode: sequence drafts every step, rewrite/shorter/angle produce a new version of one variant, and the description flags the variantId requirement for the latter. It also names the precondition (offer profile must be configured, or updated via update_offer_profile). It does not explicitly say when NOT to use it versus alternatives such as set_sequence.

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