Skip to main content
Glama
Sign In
Computer Use

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Run steps

run_steps
Destructive

Run a sequence of known UI actions in order, stopping at the first failure, and optionally return the app state after the last step.

Instructions

Run a sequence of actions in one call, in order, stopping at the first step that fails. Each step names another tool and its arguments, and runs exactly as if you had called it: the same app and site rules, element id checks and password-field refusals apply. Use it for steps you already know will follow each other, like click a field, type, press return, after reading the app with get_app_state. Element ids from that snapshot stay valid until a step reads the app again. The result lists every step's outcome; when a step fails, the steps after it do not run and the call reports an error. Put return_state on run_steps, not on a step, to get the state after the last step. At most 20 steps; run_steps cannot contain run_steps.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "steps": "<steps>"
    },
    "name": "run_steps"
  }
}

Input Schema

NameRequiredDescriptionDefault
stepsYesThe actions to run, in order
state_queryNoWith return_state, list only elements whose role, label or value contains this text, like get_app_state's query
return_stateNoPass return_state to the last step, so the result ends with the state after it (the app you last read, or the page for a browser step)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.9.0

TDQS

A4.6/5.0
Behavior5/5

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

Even though annotations already flag destructive=true, idempotent=false and openWorld=true, the description adds substantial context they cannot convey: the same permission/rule checks as direct calls, behaviour on failure (later steps skipped, error reported), element-id validity lifetime, and the 20-step cap. It also clarifies that return_state belongs on run_steps and not on a step, which is genuinely non-obvious.

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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries distinct operational information (failure semantics, id validity, limits, return_state placement). It is dense but not padded; only slight tightening would improve it.

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, yet the description compensates by describing the result ('lists every step's outcome') and the error behaviour on failure. Combined with the explicit limits and return_state guidance, an agent has everything needed to invoke this correctly.

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 the baseline would be 3, but the description goes further: it explains that each step names a tool plus its args and behaves exactly like a direct call, that return_state must be placed on the wrapper rather than a step, and that state_query mirrors get_app_state's query semantics. This resolves real ambiguity in how the nested step object is populated.

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 gives a specific verb and resource plus the key differentiator: it runs a sequence of other tools in one call, in order, halting on failure. That clearly separates it from every sibling, which each performs a single UI action (click, type_text, press_key, etc.).

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 states a clear usage condition with a concrete example ('click a field, type, press return, after reading the app with get_app_state'), which tells the agent to snapshot first, then batch. It also adds hard constraints (max 20 steps, no run_steps inside run_steps). What's missing is an explicit inverse — when to call individual tools instead of batching.

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

Deploy Server

Other Tools