Skip to main content
Glama

computer

Destructive

Controls the desktop with mouse, keyboard, and screenshot actions for pixel-level GUI automation when named accessibility targets are unavailable.

Instructions

Direct mouse/keyboard/screenshot control. Pick an action: screenshot, screenshot_region, zoom, click, double_click, right_click, middle_click, triple_click, hover, move, move_relative, scroll, scroll_horizontal, drag, drag_path, mouse_down, mouse_up, type, key, key_press, key_down, key_up, wait. screenshot is the LAST RESORT for seeing the screen: first try accessibility read_tree/find/compile_ui (names + positions) or system copy_all_text (exact page text). Coordinates default to image-space pixels of the latest screenshot; pass space:"screen" to click a position reported by accessibility. Prefer accessibility for named targets; use computer only when you need pixel-level control.

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": {
      "action": "<action>"
    },
    "name": "computer"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoLeft edge X in image-space coordinates
yNoTop edge Y in image-space coordinates
dxNoX offset in image-space pixels
dyNoY offset in image-space pixels
keyNoAlias for "combo". Alias for combo — accepted for MCP/compound backward-compatibility.
endXNoEnd X in image-space
endYNoEnd Y in image-space
pathNoStepped drag path: array of {x,y} points (min 2). When given, startX/startY/endX/endY are ignored. Press at first point, release at last.
shotNoOptional, image-space pointer actions: the id of the screenshot the coordinates were read off (each screenshot reply names it, e.g. "s3"). Refused when it is not the latest screenshot.
textNoThe text to type
comboNoKey/combo to press (e.g. "Return", "mod+s"). Space-separate for a sequence.
countNo1=single, 2=double
spaceNoCoordinate space. Omit (default) → image-space coords from the latest screenshot (the tool scales them to the screen). Pass "screen" → the positions an accessibility tree / find reports (@x,y), passed as reported, unscaled: physical pixels on Windows and Linux, POINTS on macOS (a Retina screenshot's "real" size is twice the point size).
widthNoWidth in image-space pixels
actionYesWhich sub-action to perform. See this tool's description for the enum of valid values. Required: screenshot_region/zoom: x, y, width, height; click/double_click/right_click/middle_click/triple_click/hover/move: x, y; move_relative: dx, dy; scroll: direction; scroll_horizontal: x, y, direction; drag_path: path; type: text; key_down/key_up: combo; wait: seconds.
amountNoWheel ticks (default 3)
buttonNoMouse button to click: "left" (default) or "right"
expectNoOptional post-conditions to verify after this action (same assertion types as the verify tool: window_title_contains, app_running, element_exists, element_value_contains, clipboard_contains, file_exists, file_contains, ocr_contains, file_changed_since_start). If any FAIL the action returns a DEVIATION and you must adapt. State an OUTCOME you can observe (a window title, a rendered element/chip, a status) — NOT the raw text you typed.
heightNoHeight in image-space pixels
startXNoStart X in image-space
startYNoStart Y in image-space
displayNoMonitor to capture (index from window list_displays). Default: the monitor clawdcursor last worked on, else the primary.
secondsNoDuration to wait (0.1 to 30)
directionNoScroll direction

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.24
    • changedInput schema / properties / action / description
      Previous value: -"Which sub-action to perform. See this tool's description for the enum of valid values."New value: +"Which sub-action to perform. See this tool's description for the enum of valid values. Required: screenshot_region/zoom: x, y, width, height; click/double_click/right_click/middle_click/triple_click/hover/move: x, y; move_relative: dx, dy; scroll: direction; scroll_horizontal: x, y, direction; drag_path: path; type: text; key_down/key_up: combo; wait: seconds."
  2. Changed1 schema field changedv1.5.23
    • addedInput schema / properties / shot
      Added value: +{
      +  "description": "Optional, image-space pointer actions: the id of the screenshot the coordinates were read off (each screenshot reply names it, e.g. \"s3\"). Refused when it is not the latest screenshot.",
      +  "type": "string"
      +}
  3. Changed1 schema field changedv1.5.21
    • changedInput schema / properties / space / description
      Previous value: -"Coordinate space. Omit (default) → image-space coords from the latest screenshot (scaled to physical pixels). Pass \"screen\" → a11y-snapshot coords (already physical, not scaled)."New value: +"Coordinate space. Omit (default) → image-space coords from the latest screenshot (the tool scales them to the screen). Pass \"screen\" → the positions an accessibility tree / find reports (@x,y), passed as reported, unscaled: physical pixels on Windows and Linux, POINTS on macOS (a Retina screenshot's \"real\" size is twice the point size)."
  4. First observedv1.5.16

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, non-idempotent and closed-world, so the safety profile is carried structurally; the description adds genuinely useful behavior beyond that: coordinates default to image-space of the latest screenshot, `space:"screen"` matches accessibility-reported positions including the macOS points-vs-pixels caveat, and the `shot` id is refused if stale. It still says nothing about what a destructive action loses or whether clicks are undoable, but coverage is strong.

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-loaded: purpose, then the action list, then the routing guidance, so a reader can stop early if they only need the verb. The 23-item action enumeration is long but load-bearing for a dispatcher-style tool; a few phrases (e.g. the repeated accessibility alternative) could be tightened without loss.

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 24-parameter destructive dispatcher with no output schema, the description supplies the selection logic, coordinate-space contract, and the `expect` post-condition/DEVIATION workflow that the schema only hints at. The main residual gap is return-value shape (e.g. that screenshots come back named like 's3'), which is only implied in passing.

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 per-parameter meaning is already documented, including the `space` enum's coordinate semantics. The description's coordinate-space paragraph largely restates what the `space` property description already says, adding the cross-cutting 'defaults to image-space pixels of the latest screenshot' rule but little else beyond the 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?

Opens with a concrete verb+resource statement ('Direct mouse/keyboard/screenshot control') and then enumerates the exact action set, so an agent knows precisely what surface this tool covers. It also names the sibling (`accessibility`) it overlaps with and states the dividing line, so it is distinguishable without opening the 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?

Explicit when/when-not guidance: `screenshot` is called out as LAST RESORT with two named alternatives (`accessibility read_tree`/`find`/`compile_ui`, `system copy_all_text`), and the tool overall is scoped to 'pixel-level control' versus `accessibility` for named targets. Both the preferred path and the fallback condition are stated.

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