Skip to main content
Glama

Local MCP

by com.local-mcp
OverviewDiscussionsAdmin

Ui Click

ui_click
Destructive

Clicks an element (by element_ref, at its center) or a screen coordinate (by coords). button left|right, count 2 = double-click. Returns {clicked, at:{x,y}} — clicked means the click event was POSTED at those coordinates, NOT that the app acted on it: CGEvent carries no delivery confirmation, so a busy, modal or input-ignoring app reports exactly the same success. Confirm the effect with ui_wait_for_element or ui_read_tree rather than trusting clicked. element_disabled is returned ONLY when the app actually publishes AXEnabled=false; a control that does not publish AXEnabled at all is treated as unknown and clicked. An element that publishes no position (some controls inside web pages) is asked to scroll into view; if it still has none, a single left click is done through its accessibility press action and the answer is {clicked, via:"press_action"} with no at; when that is refused too the error is no_bounds — use coords from a screenshot. Requires Accessibility permission.

Input Schema

NameRequiredDescriptionDefault
byNoDefault element if element_ref given, else coords.
countNo1 (default) or 2 for double-click.
buttonNoDefault left.
coordsNo{x,y} in global screen points.
element_refNoElement handle returned by ui_find_element or ui_read_tree; the click lands at that element's center. Needed when by=element, which is the default whenever element_ref is present.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / element_ref / description
      Added value: +"Element handle returned by ui_find_element or ui_read_tree; the click lands at that element's center. Needed when by=element, which is the default whenever element_ref is present."
  2. Changed1 schema field changed
    • removedInput schema / properties / element_ref / description
      Removed value: -"Element handle returned by ui_find_element or ui_read_tree; the click lands at that element's center. Needed when by=element, which is the default whenever element_ref is present."
  3. Changed1 schema field changed
    • addedInput schema / properties / element_ref / description
      Added value: +"Element handle returned by ui_find_element or ui_read_tree; the click lands at that element's center. Needed when by=element, which is the default whenever element_ref is present."
  4. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the annotations by warning that `clicked` only means the event was posted, not that the app acted on it, and by explaining CGEvent lack of delivery confirmation. It also discloses AXEnabled semantics, the press_action fallback, the no_bounds error, and the Accessibility permission requirement, which are critical behavioral details for this mutation tool.

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 information-dense and front-loads the core click modes, then layers in caveats. It is longer than typical, but the detail earns its place given the ambiguous success semantics of UI clicks; a slight readability cost comes from the run-on structure.

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 tool with no output schema and destructive UI interaction, the description supplies the return shape, the meaning of its fields, special return variants, error behavior, permission requirements, and verification guidance. An agent has what it needs to call the tool correctly and interpret the result.

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 the schema already documents all five parameters including defaults and enum values. The description reinforces behavior around element_ref and coords but does not add materially new parameter-level syntax beyond what the schema provides.

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 (clicks) and the two supported resource modes: an element by element_ref at its center, or a screen coordinate. This clearly distinguishes the two invocation modes without requiring the schema to be read first.

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?

Gives concrete guidance on confirming effects with ui_wait_for_element or ui_read_tree, and explains the no_bounds fallback should use coords from a screenshot. It does not explicitly compare against sibling tools such as web_click, but it covers the key in-tool decision points clearly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Local MCP toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources