Skip to main content
Glama

act

Destructive

Run ordered click, type, key, and menu steps in Windows apps in the background, verify each result, and stop at the first error or unknown outcome.

Instructions

Act in the background: steps run in order (stops at the first error or unknown outcome), then the updated state (then: auto = list + image if a step is not verified; both, image, elements, changes, none). Per-step report: ✓ invoked or effect read, = already done (nothing sent), ~ unknown outcome (batch stopped: inspect the state), ✗ failed or not reached; then the summary. Steps (do): click, double_click, right_click, type (appends text; no target = focused element), set (replaces the text), clear, key (keys "ctrl+s", "enter", "alt+f4"), select (option in a list), check, uncheck, toggle, expand, collapse, scroll (direction, amount), focus, menu (path "File > Open"), wait (text appeared, or gone=true; timeout), drag (target → to), hover. expect: text expected after the step. check: wanted state of an element ({"target":"Name","value":"Alice"}; also contains, checked, selected, expanded, focused, enabled, exists): already true → step skipped, read back after → ✓, otherwise ✗ not reached. confirm=true: paying, sending, publishing, permanent deletion… (refused otherwise, before any input); only on the user's explicit order or "yes" for THIS action. Outward ones (send, pay, publish…) also need accord: the token from the refusal, after the user's own yes. target: [N] from the last look, visible name ("Save", "button:OK", "edit:Name") or "x,y" in image pixels. Example: steps=[{"do":"set","target":"Name","text":"Alice"},{"do":"click","target":"OK"}]. Routines: remember="name" saves the batch if it is verified (✓/=, targets by name; {{x}} = variable text, only in text and check.value/contains; typed text made only of {{x}}); routine="name" (without steps) replays it, params={"x": "…"}; remember="name" with steps=[] forgets it; look lists them. foreground=true: window kept in front for the whole batch, real mouse/keyboard when the background is impossible or ignored (drag, hover, WPF/UWP/Chromium shortcuts, Tk); only with the user's consent. Panels window="quick settings", "notifications", "start": foreground=true only.

Input Schema

NameRequiredDescriptionDefault
thenNoauto
stepsNo
paramsNo
windowNo
routineNo
rememberNo
settle_msNo
foregroundNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.3.1

TDQS

A4.3/5.0
Behavior5/5

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

The description adds extensive behavioral detail beyond annotations: batch stop conditions, per-step symbols, then-mode outputs, confirm/accord safety gating, foreground escalation rules, and routine save/replay behavior. This is consistent with destructiveHint=true, openWorldHint=true, and readOnlyHint=false.

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 but appropriately dense for a highly parameterized automation tool, and it front-loads the core batch model before details. Some sections are packed into terse run-on text, but nearly every sentence carries operational meaning.

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?

For a complex UI automation tool with no output schema, the description is complete enough: it explains execution order, failure semantics, report symbols, returned state modes, confirmation safety, routines, and foreground constraints. Only minor details such as settle_ms are absent.

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 description coverage is low at the top level, and the description compensates well by explaining then modes, steps, expect, confirm, accord, target formats, routine/remember/params, foreground, and panel windows. It still leaves settle_ms unexplained and does not fully cover every top-level nuance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clarifies that this tool executes an ordered batch of UI actions in the background and explains the state/report returned afterward. It is specific about the verb and resource, but it does not clearly differentiate the tool from siblings like window, launch, or look beyond a brief mention of look listing routines.

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 gives clear usage conditions for confirm=true, accord tokens, foreground=true, and routines, including safety exclusions such as refusing confirm without explicit user instruction. However, it does not explicitly state when to choose act over sibling tools such as look, window, or launch.

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