Skip to main content
Glama
Sign In
OpenCU

OpenCU

by Daily-AC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

run_actions

Run a short sequence of known UI actions and return the final state. Use for multi-step operations when new information or approval would require stopping.

Instructions

Run a short known sequence and return its final state. Single-action tools already return text state; use this for several known actions or an inline final screenshot. Example: focus an observed field, select all, paste, then inspect the result. Stop when new information or approval is needed. Accepts {"method":"wait","ms":N} for 1–15000 ms on every platform; wait sends no input and honours person stops. Coordinate input must be first (including before any wait) and use a fresh screenshot. Stops on error or an unknown accessibility action outcome without replay; earlier actions may have run. An unknown outcome requires an explicit get_app_state before continuing. A locked pattern that refreshes indexes stops the remaining batch and returns fresh state; choose subsequent actions from that state.

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": {
      "app": "<app>",
      "actions": "<actions>"
    },
    "name": "run_actions"
  }
}

Input Schema

NameRequiredDescriptionDefault
appYesApp name or full app path; macOS bundle ID; macOS and Windows pid:<pid>; Windows process name, window title fragment, or Start-menu shortcut name; Linux desktop entry name, executable name or window title fragment
scopeNomacOS and Windows: element index from the latest returned state. Read only its retained subtree, renumbered from [1], including after actions. If it disappears, return the whole window with a notice. Linux returns INVALID_ARGUMENT.
actionsYes
disableDiffNo
waitForTextNoWait for exact, case-sensitive text in element lines only (within scope when supplied), excluding headers and window summaries, without UI actions. Use only a known expected label during a real load; omit on ordinary reads.
waitTimeoutMsNoPolling deadline for waitForText; defaults to 5000 ms. Native call timeouts remain separate.
includeScreenshotNoDefault false. Use true for visual content or coordinate input; omit for indexed controls, menus, dialogs and text editing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.7/5.0
Behavior5/5

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

Goes well past the readOnlyHint=false / openWorldHint=true annotations: it discloses that wait sends no input and honours person stops, that coordinate input must come first and requires a fresh screenshot, that the batch halts on error or an unknown accessibility outcome without replay while earlier actions may already have run, and that an unknown outcome mandates an explicit get_app_state. This is exactly the partial-failure and ordering context the annotations cannot convey.

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?

Front-loads the core purpose and the sibling distinction, then layers sequencing and failure rules with no filler sentences. It is dense — several clauses are packed into single sentences ('Stops on error or an unknown accessibility action outcome without replay; earlier actions may have run') — but nothing is redundant.

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?

For a 16-item batch tool spanning ten action variants with no output schema, it covers the highest-risk gaps: ordering rules, screenshot freshness, and partial-execution semantics on failure. Minor omissions remain — the 16-action cap and disableDiff's effect are left entirely to the schema, and the shape of the 'final state' return is only implied.

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 71%, and the description still adds real semantics beyond it: the wait method's 1–15000 ms range and cross-platform availability, and the positional constraint that coordinate input must precede all other actions including waits. It says little about waitForText, waitTimeoutMs, disableDiff, or scope, but the schema already documents those.

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?

States a specific verb and resource ('Run a short known sequence and return its final state') and explicitly distinguishes itself from the single-action siblings: 'Single-action tools already return text state; use this for several known actions or an inline final screenshot.' An agent can route to it without reading any sibling schema.

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?

Gives the exact selection rule versus click/drag/paste/press_key, supplies a concrete use case ('focus an observed field, select all, paste, then inspect the result'), and states when to stop ('when new information or approval is needed'). Explicit alternatives plus an explicit exclusions rule.

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