Skip to main content
Glama

Edit copy on existing steps

sequence_update
DestructiveIdempotent

Patch fields on already-materialised sequence steps — the surgical way to fix a typo or swap copy on a campaign that is ALREADY RUNNING (ACTIVE or PAUSED), without re-saving the whole graph and re-evaluating every lead. Leads keep their position and their scheduled actions. Pass the step _id from sequence_list FOR THIS CAMPAIGN, plus only the fields to change — anything omitted is left alone. An id from another campaign is refused. Copy fields: message, subject, note (the connection-request note), shortNote, and the A/B variants bMessage, bSubject, bNote, bShortNote. Read the step back from sequence_list first to see which of those it actually has — an EMAIL step has subject, a CONNECT step has note, and only a step with abTestingEnabled uses the b* pair. TWO EDITS ARE NOT SURGICAL AND ARE EASY TO MAKE BY ACCIDENT. Sending days or calendarType RESCHEDULES every pending activity on that step — each waiting lead is pushed to that many days from now, which moves real send times; neither field is returned by sequence_list, so do not pass them unless the user asked to change the wait. And connectWithoutMessage: true silently CLEARS that step's note, so the connection request goes out with no text. To add, remove or reorder steps, rewrite the sequence with flow_set. Do NOT use this on a DRAFTED campaign: launching rebuilds every step from the saved flow graph, which this tool does not touch, so the edit is silently reverted to the original copy the moment the campaign launches. Check status with campaign_get first. To change a draft's copy, call flow_set again with the corrected steps.

Input Schema

NameRequiredDescriptionDefault
sequencesYesThe step patches to apply.
campaignIdYesCampaign id, from `campaign_list` or `campaign_create`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, but the description goes well beyond them: it names two specific accidental-destruction paths (`days`/`calendarType` rescheduling every pending activity, `connectWithoutMessage: true` silently clearing the note) and the silent-revert behavior on drafts. That is exactly the mutation-risk context an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and scope, and every paragraph carries actionable information. It is dense and long relative to the two-parameter surface, and the `days`/`calendarType` warning appears both in the description and the schema, so a little is redundant rather than wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, graph-touching mutation with no output schema, the description covers prerequisites, cross-campaign id refusal, per-step-type field availability, two accidental-destruction hazards, and the draft-reversion trap. Nothing an agent needs to call it safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 real semantic meaning: it enumerates the copy fields, explains which fields exist per step type (EMAIL has `subject`, CONNECT has `note`), ties `b*` variants to `abTestingEnabled`, and repeats the `days`/`calendarType` hazard. Minor duplication with the schema's own descriptions keeps it off a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('patch fields on already-materialised sequence steps') and immediately scopes it to surgical copy edits on running campaigns. It explicitly distinguishes itself from `flow_set` (structural rewrite) and `campaign_update`, so an agent can route correctly without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit preconditions (check `status` with `campaign_get`; campaign must be ACTIVE or PAUSED), explicit exclusions (do NOT use on DRAFTED campaigns, with the reason — edits are reverted on launch), and explicit alternatives (`flow_set` for add/remove/reorder and for drafts). This is the full when/when-not/alternative triad.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources