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

Annotations already cover the read-only/idempotent profile, and the description adds genuinely new behavior: records are created at launch so the list is empty beforehand, and the ids returned are the patch handles for `sequence_update`, only safe when ACTIVE or PAUSED. That is lifecycle and safety context an agent cannot get from the annotations.

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?

Front-loads the definition, then the contrast with `flow_get`, then the empty-before-launch caveat and the `sequence_update` dependency. Every sentence carries information, though the dense backtick references and parenthetical warnings make it slightly heavier than needed.

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 single-param read tool with annotations and no output schema, nothing material is missing: lifecycle timing, sibling relationships, and the downstream use of returned ids are all covered.

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% and there is a single parameter whose meaning (campaign id, sourced from `campaign_list`/`campaign_create`) is fully documented in the schema. The description implies the campaign must be launched but adds no syntax or format detail beyond that baseline.

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 resource (the materialised sequence steps the runtime executes) with a clear verb, and immediately contrasts itself with `flow_get`: "the flow is the design, these are the live steps with their ids, delays and copy." An agent can pick this tool over its closest sibling without opening 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?

Explicit when-to-use and when-not: use it after launch, and "on a DRAFTED campaign read `flow_get` instead." It also names downstream steps (`sequence_leads_at_step`, `sequence_update`) and the state constraint that makes `sequence_update` safe, giving a complete routing picture.

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