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

live_run_step

Executes a single automation step live against the target tab and returns its result, letting you test one action or read page state without building a full flow.

Instructions

Runs one plain step (locator/page/assert/variable -- not a Conditional/Repeat/Iterate) live against the side panel's target tab (the pinned tab, or the active tab if none is pinned), the same way a step's own Play button would, and returns its result: capturedValue for a variable step, and generically returnValue -- whatever the underlying Playwright call itself returned (e.g. {kind:"locator", method:"count", selector:"li.item"} or {kind:"page", method:"title"}), not just the fixed capture trio. Useful for trying one action, or reading one piece of page state, without building a whole flow first. Requires the side panel open and connected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepYesA 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.
projectNoPath to the project root (same folder the side panel connects to). Defaults to the EASYSPEC_PROJECT environment variable if omitted.
sessionNoWhich connected side panel to target, by its connection id (see live_status) -- only needed when more than one side panel is connected to the same project.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.4

TDQS

A4.3/5.0
Behavior3/5

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

The description discloses that the step runs live against the side panel's target tab and requires an open/connected side panel, and it notes the return shape. However, it does not explicitly warn that action steps can actually perform side effects in the browser, which is important for an execution tool with no annotations to fall back on.

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 description is front-loaded with the core purpose and return behavior, then details the step object thoroughly. It is somewhat long and dense with run-on sections, but nearly every sentence carries necessary semantic information for correct invocation.

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 tool with no output schema and no annotations, the description is remarkably complete: it specifies target selection, required connection state, return values, step shape, scope semantics, raw vs util behavior, and parameter defaults. An agent can invoke the tool correctly without needing additional context.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter descriptions go well beyond the minimal schema, providing a detailed field-by-field explanation for the nested step object, including selector expression syntax, scope naming/reuse rules, raw step limitations, util-call encoding, and the meaning of project and session. This gives an agent everything needed to construct correct arguments.

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 description clearly states that the tool runs one plain step live against the side panel's target tab and returns the step's result, with concrete examples. It distinguishes itself from related tools by emphasizing single-step execution and excluding conditional/repeat/iterate step kinds.

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

Usage Guidelines4/5

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

It explains when the tool is useful—trying one action or reading page state without building a flow—and clarifies that raw steps are only for inline code, while util calls use a different kind. It doesn't explicitly name alternative tools like live_run_step_range or live_run_multiple_steps, but the single-step focus is clear.

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