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

live_run_step_range

Executes a contiguous range of steps from a saved flow as a live tracked run, re-verifying only the specified steps with seeded context from dataset/params.

Instructions

Runs a contiguous [from, to] slice of an already-SAVED flow's own top-level steps live, as a real tracked Run (shows up in the Runs tab with live per-step status dots, same as live_replay_flow/live_start_run) -- for re-verifying just the steps you just added/changed instead of a full live_replay_flow from step 0 every time. Context is seeded the same way a fresh replay's first iteration would be (the chosen dataset/params -- or the flow's own first/default dataset if neither is given -- plus state-var defaults), since a mid-flow slice has no prior-steps history to inherit values from otherwise: if the steps in range reference a param/state-var, pass a dataset (or params) that actually defines it, or the slice will see it as undefined even though a full replay from step 0 would have set it correctly by this point. results has one entry per step actually attempted (stops at the first failure, same as a full replay) with its 0-based index in the flow's own step list. Blocks until the slice finishes (or fails) and moves from the Runs tab's current list to its history, same as live_replay_flow. Requires the side panel open and connected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesLast step index to run (0-based, inclusive)
fromYesFirst step index to run (0-based, inclusive)
flowIdYes
paramsNo
datasetNoName of an existing flow-data dataset to use as the base params
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
Behavior4/5

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

With no annotations provided, the description carries the full burden of explaining side effects. It states that the tool blocks until the slice finishes or fails, that the run moves from the current list to history, and that context is seeded from the chosen dataset/params or flow defaults. It does not discuss authentication or error handling, but the main behavioral consequences are disclosed.

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

Conciseness2/5

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

The description is overly long and repetitive, with the 'same as live_replay_flow' comparison, the 'from step 0' phrasing, and the context-seeding caveat repeated multiple times. It is front-loaded with the core purpose, but the dense parentheticals and run-on sentences make it harder to parse than necessary.

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

Completeness4/5

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

Given that there is no output schema, the description provides useful context about result granularity (one entry per step attempted), blocking behavior, and lifecycle status. It does not specify the exact return shape, but the essential operational context for calling the tool is present.

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 schema already covers descriptions for from, to, dataset, project, and session, and the description adds important context about how dataset and params interact, including the fallback to flow defaults. It also explains that a missing param or state-var referenced by the steps will be undefined unless provided, which helps the agent supply the right 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 the action (runs a contiguous slice of a saved flow's top-level steps live as a tracked run) and distinguishes it from the sibling live_replay_flow by focusing on a partial range rather than a full replay. It also names the intended use case of re-verifying recently added or changed steps, making the tool's purpose unambiguous.

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?

The description explicitly says when to use this tool instead of live_replay_flow: to re-verify just added/changed steps without running the full flow from step 0. It also gives operational prerequisites, such as requiring the side panel open and connected, and clarifies how the run appears in the Runs tab.

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