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

Annotations already declare this is a non-idempotent, non-destructive mutation. The description adds useful behavior beyond that: steps are appended by default, passing a 0-based position inserts and shifts later steps down, and one call is needed per step. It does not cover permission requirements or error conditions, so it is not fully exhaustive.

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 action and then proceeds logically through the drip concept, the step_type-to-field mapping, the position behavior, and a final usage note. Every sentence carries information relevant to invoking the tool correctly.

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 an 11-parameter tool with nested objects and 100% schema coverage, the description covers the essential conditional usage and append/insert behavior. It omits some contextual details, such as whether the target sequence must be in a particular state (e.g., paused) to accept steps, which would be valuable given sibling tools for activating and pausing sequences.

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 adds meaningful conditional mapping: it tells the agent which field(s) to supply for each step_type (email, delay, condition, action). This consolidates the schema's per-field notes but does not add edge-case semantics (e.g., what happens if mismatched fields are passed).

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 ('Add a step to a sequence') and explains the drip-building context. However, it does not explicitly differentiate from sibling tools like meisa_update_sequence_step or meisa_reorder_sequence_steps, leaving the agent to infer that this tool is only for appending new steps.

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?

Provides clear usage context such as 'To build a full drip, call this once per step in order' and describes the typical email -> delay flow. It stops short of stating when not to use it (e.g., for editing existing steps) or naming the relevant alternatives, so it earns a 4 rather than 5.

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