Skip to main content
Glama

flow-execute

Run saved UI automation flows for iOS and Android apps, executing steps like taps, gestures, and assertions on devices, and returning a structured report.

Instructions

Run a saved flow from the .argent/flows/ directory, or an explicit boundary-managed flow_path. Steps run in order: launch starts an app from scratch (terminate + relaunch) and waits until it is ready; tool calls dispatch through the registry; tap/long-press/type resolve a selector to an element and act on it (tap: { on, times: 2 } double-taps; long-press: { on, duration } presses and holds; tap/long-press alternatively take a raw normalized point — bare { x, y } or on: { x, y }; any selector may scope its matches geometrically, the CSS combinators read off frames: within: <selector> (descendant — inside that container's frame), after: <selector> (CSS ~ — following it in reading order), next: <selector> (CSS + — the nearest such follower, which unlike CSS reaches past a non-matching neighbour rather than failing), plus any: true (CSS * — legal only WITH a scope and never beside text/id/role). Scopes nest to disambiguate — within: { id: card, within: { id: list } } reads "inside card inside list", each container's frame inside the next); scroll-to scrolls (momentum-free) until a target is visible; pinch zooms (pinch: { on?, scale } — scale > 1 in, < 1 out; screen center when on is omitted); rotate is the two-finger rotation gesture (rotate: { on?, by } — degrees, + clockwise, within ±3000°; screen center when on is omitted; distinct from the rotate tool, which changes device orientation); await waits for a UI condition, and additionally takes the one condition that has no selector: idle: true waits until the screen has content and stops moving in BOTH the UI tree and the rendered pixels (it never fails a run — a screen that never settles passes carrying a warning, which is what makes it safe to persist; the one outcome that does stop the run is an error for a tree source that could not be read at all — a broken window rather than a verdict about the app, which leaves the run not-ok and skips every later step; it says nothing about WHICH screen settled — a dropped tap leaves the source screen perfectly idle — so pair it with the element check that names the destination); wait pauses for a fixed number of milliseconds; assert checks one now; snapshot diffs a screenshot — or, with cropOn: <selector>, one element's cropped region — against a stored baseline (a missing baseline fails the step — set updateBaselines to adopt the current screen; a cropped element whose size drifted fails on dimensions); echo annotates; run executes another flow inline — a YAML path resolved against the directory of the flow file that references it (co-located runs only). A when: block (condition + steps:, no else) runs its steps only if the condition holds — checked once with the short assert grace — for one-sided divergences like interstitials and coach marks; a skipped block reports distinctly and failures inside an entered block are real failures. A flow that begins with a launch step is a self-contained e2e flow; one that doesn't runs against the device's current state. Device id is injected by the runner (flows store none) — pass device or platform to pick one, else the single booted device is used. On Chromium a launch step's value is an Electron app path ({ chromium: | { path, args } }) the runner boots (on the tool-server host) rather than an installed app id it relaunches. With no explicit device, a run whose leading launch is unambiguously chromium (platform: chromium, or a lone { chromium: … } target) boots that app and starts there — following a leading run:, so a fragment that composes a chromium e2e flow boots too; otherwise the first launch attaches to an already-running instance and never kills it. Every later launch — a nested e2e flow's own, or a mid-flow relaunch — boots a fresh instance the run moves onto; an instance the run already owns for that same app is killed first (its exit awaited) so the replacement can't lose the race against its single-instance lock. Instances the runner still owns at run end are torn down then. A launch declaring no id for the run's platform is an error, not a cue to switch platforms. Every step hard-stops the flow on failure; later steps are reported as skipped. Returns a structured report ({ flow, device, executionPrerequisite, ok, aborted?, passed, failed, skipped, errored, steps }) — device is the device the run STARTED on; when launches moved it onto runner-booted instances, each names its instance in that step's reason and marks the move — run moved off <id>, or retired <id> (same app relaunched) when the instance it left was the one killed — a relaunch that retired an older owned instance names both.

If a fragment has an execution prerequisite and prerequisiteAcknowledged is not set to true, the tool returns a notice with the prerequisite instead of running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoName of a saved flow to run from `.argent/flows` (e.g. "settings-explore"). Omit when flow_path is set.
deviceNoDevice id to run against (iOS UDID, Android/Vega serial, Chromium id) — the id list-devices reports. Auto-detected when omitted, but only when exactly one booted device matches (optionally narrowed by `platform`); with several booted the run fails and lists them, so pass this explicitly whenever more than one device is up.
platformNoRestrict auto-detection to this platform when several devices are booted. `chromium` does more than filter: with no `device` it SELECTS the self-boot branch for an e2e flow - the runner boots an Electron instance from the `launch` step's chromium value and tears it down after the run (a single-key `launch: { chromium: … }` map selects it on its own, without this parameter). When it selects that branch it never falls back to device auto-detection (a fragment, or an e2e launch map with no `chromium` key, still does), and the launch value must be a real Electron app path on the tool-server host: a bare-string `launch:` - what the recorder writes - holds an installed-app bundle id, so passing `chromium` for one fails the whole run with `Electron boot: path does not exist`. Edit the launch to `{ chromium: <app path> }` first.
flow_fileNoPath to the flow .yaml as readable by the tool-server. Internal — the argent client derives it from project_root and name automatically; leave unset.
flow_pathNoAbsolute path to a co-located flow .yaml on the client and tool server's shared filesystem. This must be supplied through the file-input boundary. For remote execution, pass name + project_root instead.
project_rootYesAbsolute path to the calling agent's project root — the cwd it is working in. With name, the saved flow is read from `.argent/flows/<name>.yaml` under this root; with flow_path, the flow, its run: siblings, and baselines all resolve beside the YAML instead, so pass the agent's cwd.
updateBaselinesNoWrite/refresh screenshot baselines for `snapshot` steps instead of diffing against them.
prerequisiteAcknowledgedNoSet to true to confirm the execution prerequisite has been met. Required (LLM path) when a fragment defines an executionPrerequisite.
Behavior5/5

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

No annotations are provided, so this description carries full burden—and it delivers. It discloses hard-stop failure semantics ('Every step hard-stops the flow on failure'), device lifecycle behavior (kills/retires owned instances, tears down at run end), idle's never-fail warning behavior, and prerequisite notice behavior. This goes far beyond a basic read/write characterization.

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 long and dense, but the tool is complex and the text is organized by step type with a clear front-loaded opener. Some repetition and a very long selector parenthetical make it less crisp than ideal, but each major behavior earns its place. Score 4.

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?

There is no output schema, but the description explicitly enumerates the structured return report and prerequisite behavior. It also covers run semantics, device selection, chromium edge cases, and failure/skipping. For a tool of this complexity, this is comprehensive.

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 baseline is 3, and the description adds contextual parameters: it explains device auto-detection failure with multiple booted devices, the chromium self-boot branch vs fallback, and flow_path co-location rules. It reinforces schema descriptions without repeating them verbatim. This additional context justifies a 4.

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 states a specific action: 'Run a saved flow from the .argent/flows/ directory, or an explicit boundary-managed flow_path.' This clearly identifies both the operation and the resource, and the focus on execution distinguishes it from sibling recording/utility flow tools. The rest of the description elaborates on execution semantics but the purpose is immediately unambiguous.

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?

The description gives substantial context: when a flow is self-contained vs runs against current state, how device/platform selection works, and prerequisite acknowledgment. It even notes step-level alternatives like the rotate gesture vs the rotate tool. However, it never explicitly compares flow-execute to sibling tools like run-sequence or the gesture/tap tools, so exclusion guidance is implied rather than stated.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/software-mansion/argent'

If you have feedback or need assistance with the MCP directory API, please join our Discord server