Skip to main content
Glama

run_steps

Batch sequential UI actions (tap, type, swipe, wait) into one call to eliminate per-gesture round-trips for fast flows like login and form filling.

Instructions

Execute an ordered batch of UI actions in ONE call via the native backend (idb/mobilecli, sub-second; Maestro fallback per step). Eliminates per-gesture MCP round-trips for fast continuous flows (login, navigation, form fill). Step actions: tap {x,y} · tapText {text|id} · type {text,submit} · key · swipe · waitFor {text,timeoutMs} · assertVisible {text} · waitMs · screenshot. Prefer waitFor over waitMs to act the instant the UI is ready instead of sleeping. WebView note: web-rendered text is invisible to tapText — use tap {x,y} for it; type uses real keystrokes so React onChange fires. Stops at the first failed step unless stopOnError:false. bundleId is only needed for the Maestro fallback (auto-detected otherwise). When to use: pick run_steps for >2 known sequential gestures (login, navigation, form fill); use run_flow for Maestro assertions/conditionals/loops/retries; use the individual gesture tools (tap_on, swipe, …) for a single exploratory action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
udidYesSimulator / device UDID (from device_list)
bundleIdNoApp bundle id for Maestro fallbacks (auto-detected from the foreground app if omitted).
stepsYesOrdered list of actions to perform.
stopOnErrorNoStop at the first failed step (default true). false = run all and report each.
stepDelayMsNoOptional fixed delay inserted after every step (default 0).
Behavior5/5

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

Discloses key behaviors: native backend with Maestro fallback, stops on first error unless stopOnError:false, bundleId auto-detection, WebView limitations for tapText, real keystrokes for type. No annotations present, so description carries full burden and meets it well.

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?

Description is well-structured and front-loaded with core purpose and value, followed by action list, tips, and usage guidance. Though lengthy, each sentence serves a purpose; could trim minor redundancies.

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?

Given the complexity (many step types, no output schema), the description is comprehensive: covers all actions, edge cases (WebView), error behavior, and timing recommendations. No missing critical information.

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 covers all 5 parameters (100% coverage), so baseline 3. Description adds value with context: bundleId auto-detection, stepDelayMs optional, stopOnError default true, and succinct explanations for each action type in the steps array.

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 tool executes an ordered batch of UI actions in one call for fast continuous flows, and distinguishes from siblings like run_flow and individual gesture tools.

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?

Explicitly provides when-to-use vs alternatives: use run_steps for >2 known sequential gestures, run_flow for assertions/retries, individual tools for single exploratory actions. Also includes best practices like preferring waitFor over waitMs.

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/hoainho/podium-mcp'

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