Skip to main content
Glama
munimtechnologies

Computer Use

by munimtechnologies
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

Click

click
Destructive

Click UI elements by accessibility ID (works even off-screen) or at exact screen coordinates to trigger real actions in the target application.

Instructions

Click an element by element_id (preferred: it uses the accessibility press action, so it works even when the element is scrolled out of view) or at absolute screen coordinates taken from a screenshot or zoom. Pass element_id or x and y, not both. Use browser_click for pages in the agent's Chrome tabs, right_click for context menus, and drag for press-move-release. The click reaches the target app for real and can trigger any action the user could, so read the target with get_app_state first. The agent's own pointer overlay moves to the target. On macOS the user's mouse pointer never moves; on Windows and Linux a target that ignores background input gets real mouse input, which moves the user's pointer, and the result then says via cursor.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoScreen x coordinate in points, used together with y when no element_id is given
yNoScreen y coordinate in points, used together with x when no element_id is given
element_idNoElement id from the most recent get_app_state snapshot, e.g. e12. Preferred over coordinates.
click_countNo1 for a single click (default), 2 for a double-click

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.3.1
    • changedInput schema / properties / click_count / description
      Previous value: -"1 for single, 2 for double-click"New value: +"1 for a single click (default), 2 for a double-click"
    • changedInput schema / properties / element_id / description
      Previous value: -"Element id from get_app_state, e.g. e12"New value: +"Element id from the most recent get_app_state snapshot, e.g. e12. Preferred over coordinates."
    • addedInput schema / properties / x / description
      Added value: +"Screen x coordinate in points, used together with y when no element_id is given"
    • addedInput schema / properties / y / description
      Added value: +"Screen y coordinate in points, used together with x when no element_id is given"
  2. First observedv0.3.0

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations by warning that the click reaches the real target app and can trigger any user-possible action, recommending get_app_state first. It discloses the pointer overlay behavior and the platform-specific macOS vs Windows/Linux mouse movement differences, which is high-value behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence delivers essential information: invocation modes, alternatives, mutual exclusivity, real-world effects, and platform caveats. Content is front-loaded with the core action and preferred input, then flows into usage and behavioral details without redundancy.

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 click tool with rich annotations and full schema coverage, the description covers all operational context: how to target, when to prefer element_id, when to use alternatives, what side effects to expect, and platform-specific pointer behavior. Nothing an agent needs to invoke it correctly is missing.

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?

The schema already describes all four parameters with 100% coverage. The description adds semantic value by specifying that element_id comes from the most recent get_app_state snapshot, coordinates are in points taken from a screenshot/zoom, and that element_id is preferred over coordinates. This is above the baseline 3.

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 description states a clear verb+resource: clicking an element either by element_id or by screen coordinates. It actively distinguishes itself from sibling tools like browser_click, right_click, and drag, so an agent can select it confidently.

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?

Provides explicit routing guidance: use browser_click for Chrome tabs, right_click for context menus, and drag for press-move-release. It also states the exclusive-or constraint between element_id and x/y, and explains when each input mode is appropriate.

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