Skip to main content
Glama
Sign In
computer-agent-labs

terminal-use

by computer-agent-labs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Click in terminal

terminal_click
Destructive

Click a specific terminal cell to interact with mouse-aware TUIs; preview coordinates first with a magenta ring, then execute the click when confirmed.

Instructions

Deliver a left mouse-button click at a cell in the terminal. Only works when the program currently in the foreground has opted into mouse tracking (vim with set mouse=a, fzf, lazygit, less with mouse mode, etc.) — at a plain shell prompt mouse mode is off and the click would just print escape sequences as text, so we refuse the actual click in that case.

Coordinates are 1-indexed and refer to the live screen viewport: col 1, row 1 is the top-left cell, and the bottom-right cell is (terminal width, terminal height) which you can see via terminal_read's state header.

PREVIEW MODE (default preview: true): does NOT click. Returns a PNG with a bright magenta ring + dot drawn around the target cell so you can verify your coordinates. Always do this first when you are not 100% sure where the click should land — TUIs often have destructive actions one click away (delete branch, kill process, etc.).

EXECUTE MODE (preview: false): actually sends the mouse press+release sequence and settles for output. Use this only after you've previewed and confirmed, or when you're confident.

CAVEATS: idleMs and maxWaitMs are ignored in preview mode (preview doesn't settle). When the target cell is near the right edge of the viewport, the coordinate label drawn next to the magenta ring may be clipped — the ring itself is always within frame, so trust it over the label.

Input Schema

NameRequiredDescriptionDefault
colYes1-indexed column. Column 1 is the leftmost cell on the visible viewport.
rowYes1-indexed row. Row 1 is the top of the visible viewport.
idleMsNo
previewNoWhen true (DEFAULT), render a PNG with a bright magenta ring around the target cell WITHOUT actually clicking. When false, deliver the click and settle for output. Set to false explicitly when you are confident about the coordinates.
filePathNoPreview only: absolute path to write the PNG to. If unset, image is inlined as base64.
maxWaitMsNo
sessionIdYesNumeric id of the session to target. Get one by calling terminal_create. Use terminal_list to enumerate currently-known ids.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, openWorldHint=true, idempotentHint=false): it discloses the refusal behavior when mouse mode is off, warns that TUIs often have destructive actions one click away, explains that idleMs/maxWaitMs are ignored in preview, and notes the coordinate-label clipping at the right edge. This is exactly the extra runtime context annotations cannot carry.

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 action, then uses clear PREVIEW/EXECUTE/CAVEATS sections so the reader can scan to what matters. The prose is dense and slightly long (e.g. the parenthetical TUI example list), but nearly every sentence carries actionable information.

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 destructive, non-idempotent 7-parameter tool with no output schema, the description covers the safety protocol, coordinate semantics, return artifact (PNG), and edge cases. The remaining gap is the execute-mode output and the exact semantics of idleMs/maxWaitMs outside preview.

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 adds real meaning: it pins the coordinate frame to the live viewport, explains how to obtain terminal width/height via terminal_read, and documents that preview is the default and that idleMs/maxWaitMs are no-ops in preview. It stops short of saying what idleMs and maxWaitMs actually control in execute mode, which the schema leaves undocumented.

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 precise verb+resource ("Deliver a left mouse-button click at a cell in the terminal") and scopes it to a specific coordinate system, which cleanly disambiguates it from sibling input tools like terminal_press and terminal_type. The mouse-tracking precondition further narrows exactly what this tool is for.

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?

Explicitly states the precondition that gates use (foreground program must have mouse tracking on, otherwise the click is refused) and gives clear preview-first-then-execute guidance. It does not name sibling alternatives such as terminal_press, but the when/when-not conditions here are strong enough to route the agent correctly.

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