Skip to main content
Glama
Yan-Vi
by Yan-Vi

update_step

Patch specific fields on an existing flow step using a dot-separated path, applying only the provided changes.

Instructions

Patch fields on an existing step. stepPath is dot-separated indices into nested .steps arrays, e.g. "2.0" is the 1st step inside the 3rd top-level step's own body.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
patchYesA step object: { kind, method, selector?, pageObjectName?, pageObjectMethod?, pageObjectArgs?, elementAlias?, scopeName?, scopeSelector?, args?, options?, negate?, variable?, raw?, condition?, init?, update?, steps?, iterableName?, itemVarName? } -- same shape as a flow.json step; see get_flow on an existing flow for real examples of each kind. `selector`/`scopeSelector` are Playwright locator-chain EXPRESSIONS (see get_page_object's own description), not bare selector-engine strings -- e.g. "getByRole('button', { name: 'Submit' })", spliced as page.<selector> (or <scope>.<selector> when scoped) in generated code. scopeName/scopeSelector only apply to a step NOT bound to a page-object method (a page-object-bound step's scope comes from that method's own scope assignment instead -- see set_method_scope): scopeSelector defines a new flow-local scope (reused by any later step in this SAME flow that sets just scopeName to the same value); a step with only scopeName reuses whichever earlier step in this flow first defined that name. `kind: "raw"` is ONLY for genuinely inline, unnamed code (the `raw` field, its own JS/TS statement(s)). Calling a shared, project-wide Util function instead (see create_util/set_util_body/set_util_params/set_util_group_name) is NOT a `raw` step at all -- the step's own `kind` IS the util's current group name (every util always belongs to a group, defaulting to "custom-utils"; see list_util_groups), and `method` names which function within it, exactly like kind:"context"+method:"clearCookies" -- e.g. { kind: "custom-utils", method: "connectDb", args?, variable? }. Look up a util's current groupName via get_util/list_utils before authoring a step that calls it.
flowIdYes
projectNoPath to the project root (same folder the side panel connects to). Defaults to the EASYSPEC_PROJECT environment variable if omitted.
stepPathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.4

TDQS

B3.3/5.0
Behavior3/5

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

The description thoroughly explains stepPath format and patch object semantics (raw, utils, scopes), but does not disclose core behavior such as whether patching is a deep merge, what happens if the stepPath does not exist, or if the update is persisted. Since no annotations are provided, this is a notable gap.

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?

The main description is concise and front-loaded with purpose. The patch parameter description is long but well-structured and necessary given the complexity of the step object; it does not feel redundant.

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

Completeness3/5

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

The description covers stepPath and patch extensively, but flowId lacks any explanation. It also omits return value, error behavior, and whether the patch is additive or replacing. Given no output schema, not all gaps are critical, but flowId is a clear hole.

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?

The description adds significant meaning beyond the schema for stepPath (dot-separated indices) and patch (detailed step object structure, raw/utils/scope rules). project has a schema description. flowId remains unexplained, but 3 of 4 parameters are meaningfully described.

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

Purpose4/5

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

The description clearly states the tool patches fields on an existing step, with a specific verb, resource, and scope. It distinguishes from add_step/remove_step by emphasizing 'existing', though it does not explicitly name sibling alternatives.

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

Usage Guidelines2/5

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

No guidance is provided on when to use update_step versus add_step, add_multiple_steps, remove_step, or copy_steps. The description implies modification of existing steps, but does not state a decision procedure or alternatives.

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