Skip to main content
Glama

flow-execute

Run saved automation sequences that launch apps, interact with UI elements, verify conditions, and capture screenshots across iOS, Android, and Chromium.

Instructions

Run a saved flow from the .argent/flows/ directory. 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 }); 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; wait pauses for a fixed number of milliseconds; assert checks one now; snapshot diffs a screenshot against a stored baseline (a missing baseline fails the step — set updateBaselines to adopt the current screen); echo annotates; run executes a referenced fragment inline. 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. For a Chromium e2e flow the launch step's chromium value is an Electron app path ({ chromium: | { path, args } }); the runner boots a fresh instance from it (on the tool-server host) and tears it down when the run ends, unless an explicit device pins an already-running instance. Every step hard-stops the flow on failure; later steps are reported as skipped. Returns a structured report ({ ok, passed, failed, skipped, errored, steps }).

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
nameYesName of the flow to run (e.g. "settings-explore")
deviceNoDevice id to run against (iOS UDID, Android/Vega serial, Chromium id). Auto-detected when omitted.
platformNoRestrict auto-detection to this platform when several devices are booted.
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.
project_rootYesAbsolute path to the project root directory that contains `.argent/flows/<name>.yaml`.
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.
Behavior4/5

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

With no annotations, the description carries the full burden. It explains step ordering, failure handling ('hard-stops the flow on failure'), device selection rules, prerequisite acknowledgment, and the structured report return. This provides rich behavioral context beyond the tool's basic purpose.

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

Conciseness3/5

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

The description is verbose, covering extensive step details in a long paragraph. While informative, it is not succinct and could be restructured to front-load critical information for quick agent selection.

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 the complexity of flow execution with multiple step types, the description covers essential aspects: flow structure, step semantics, device selection, prerequisites, and return value. However, it lacks explicit error handling or timeout details, which are important for completeness.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline 3. The description adds some context for 'updateBaselines' and 'prerequisiteAcknowledged' by linking them to flow steps, but for 'device' and 'platform' it largely repeats the schema. Overall, marginal added value over schema.

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 opens with 'Run a saved flow from the .argent/flows/ directory.' This clearly states the verb (run) and resource (saved flow) and distinguishes it from sibling tools that perform single actions or debug operations.

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

Usage Guidelines3/5

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

The description explains how the tool works but does not explicitly state when to use it versus alternative tools (e.g., individual gesture tools). Only a brief note distinguishes the 'rotate' step from the sibling 'rotate' tool. No when-not or alternative recommendations are provided.

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