Skip to main content
Glama

updateStep

Edits an existing step: its text, description, answer type, content, or whether it is required. Pass only the fields you want to change, except that changing type also requires the matching content for the new type (unless the new type takes none — YesNo gets its fixed Yes/No pair automatically). Changing a step to TriggeredEmail drops its text along with its old content, and is rejected when that step is the task's first one; changing a TriggeredEmail step to another type discards its email configuration. On a draft or scheduled beta project the change is applied immediately. On a running or paused beta project the change is STAGED: testers do not see it until commitTaskChanges publishes all staged changes (revertTaskChanges discards them; getBetaTasks with version 'unpublished' shows the staged state). While staging, these tools accept BOTH the live id and the staged id of a task or step, but always respond with the STAGED row — expect ids you did not pass in, with liveVersionId linking back to the live row. Content of finished or archived beta projects cannot be edited.

Input Schema

NameRequiredDescriptionDefault
textNoThe step's question or title (up to 128 characters). A TriggeredEmail step has none; passing one for it is rejected.
typeNoThe kind of step. MultipleChoices, SingleChoice, Rate, Ranking and TriggeredEmail REQUIRE a content shaped for the type (a choices array, a choices array, a scale object, an items array, an email object). FreeText, Instructions and File take no content and reject one. YesNo takes no authored content either: omit it and the fixed Yes / No pair is set automatically, though echoing that exact pair back is accepted so a step read from getBetaTasks round-trips. TriggeredEmail is not a step testers see or answer: it sends an email the moment a tester answers the step immediately before it, so it takes no "text" and can never be the first step of a task.
stepIdYesID of the step to edit, from getBetaTasks. Never invent ids.
taskIdYesID of the task, from getBetaTasks. Never invent ids.
contentNoThe step configuration, shaped by type: for MultipleChoices/SingleChoice an array of at least 2 { choice } options with non-empty texts, optionally plus ONE final { choice: "Other", other: true } option that lets the tester type a free answer (its label is fixed: choice must be the literal text "Other", any other wording is rejected); for Rate an object { scale (number, 3 or more), symbol ("Thumb", "Star" or "Square"), lowerText?, higherText? (labels for the scale ends, up to 20 characters, default empty) }; for Ranking an array of at least 2 items { id (a v4 UUID you generate), text } with unique ids and unique texts; for TriggeredEmail an object { to, subject, message, cc? } where to is { allManagers?: boolean, allTesters?: boolean, tagsIds?: string[], personFieldIds?: string[] } and names at least one audience, subject is plain text of at most 128 characters and takes no variables (nothing replaces them there, so the recipient would read the braces), message is the email body as basic HTML reading at most 4096 characters of text, and cc is a list of Person custom field ids. Any other key of the email object or of to is rejected rather than dropped, so bcc and to.emails are not accepted: nothing would send to them. tagsIds are tester tag ids from listTesterTags, and ONLY the entries it marks assignable: a computed smart tag is rejected because a triggered email cannot be sent to one. personFieldIds and cc are ids of Person-type fields from listCustomFields; a personFieldIds field routes the email to the manager-persons that tester recorded in it, cc puts them in copy. The email goes out the first time a tester answers or skips the step before it (skipping a whole optional task sends nothing), one email per tester, and the audiences reach: allTesters ONLY that tester, never every tester in the beta project; tagsIds that same tester, only if they carry one of the tags (tester tags never reach managers, and beta labels are not tags); allManagers every manager on the beta project. To notify a manager when a tester finishes a task, make this the task's last step and use allManagers or personFieldIds. message may use these tester variables: {{USERNAME}}, {{FULL_NAME}}, {{ADDRESS}}, {{EMAIL}}, {{PHONE}}, {{PROJECT_NAME}}, {{WORKSPACE}}, {{REMAINING_PROJECT_DAYS}}, {{CURRENT_WEEK_DAY}}. The {{MANAGER_*}} ones belong to invitations and are rejected here. On an SDK beta project the audience must be managers only (allManagers), because its testers are not workspace testers and every other audience would reach nobody. REQUIRED for MultipleChoices, SingleChoice, Rate, Ranking and TriggeredEmail; omitting it is rejected. Must be OMITTED for FreeText, Instructions and File; passing one is rejected. Omit it for YesNo too (its answers are fixed to Yes / No, set automatically); passing that exact pair back is accepted, anything else is rejected. Pass the array or object value itself, not a JSON-encoded string. Call getBetaTasks to see the current shape of existing steps.
requiredNoWhether the tester must answer this step.
productIdYesID of the beta project to query. Get valid IDs from the listProducts tool.
descriptionNoSupporting detail shown under the step (up to 1024 characters of text; basic HTML is allowed).

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?

Far beyond the annotations, it discloses that writes are immediate on draft/scheduled projects but STAGED on running/paused ones, that responses return the staged row with ids the caller never passed, and that liveVersionId links back. It also flags data loss explicitly: converting to TriggeredEmail drops text and discards email configuration on the reverse conversion, and it explains rejection conditions such as a TriggeredEmail step being the task's first. The destructiveHint=false annotation is about resource deletion, not field overwrites, so this is not a contradiction, but the description correctly carries the risk disclosure the annotation does not.

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 action and the partial-update rule before the conditional and staging details. The prose is dense and runs as a single long block, and some staging/tool-cross-reference material could arguably live in a shared conventions doc, but nearly every clause carries operational consequence.

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 an 8-parameter mutation tool with no output schema, the description covers change semantics, staging lifecycle, id-return behavior, permission/state restrictions, and the sibling tools needed to supply valid ids and complete the workflow. Little an agent needs in order to call it correctly 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 description coverage is 100%, so the baseline is 3, but the description adds meaning the per-parameter schema cannot: the conditional dependency between 'type' and 'content', and the rule that fields you omit are left untouched. It also routes the agent to getBetaTasks to inspect the current shape rather than guessing.

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?

The opening sentence names a specific verb (Edits) and resource (an existing step) and enumerates the mutable facets: text, description, answer type, content, required. An agent can immediately distinguish this from createStep, deleteStep, and updateStepsOrder without opening a 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?

It states the partial-update contract ('Pass only the fields you want to change'), the cross-field dependency (changing type requires matching content), the terminal case that cannot be edited (finished or archived beta projects), and it names the correct companions for each follow-up need: commitTaskChanges, revertTaskChanges, getBetaTasks, listTesterTags, listCustomFields.

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