Skip to main content
Glama
Sign In
OpenCU

OpenCU

by Daily-AC
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

click

Activate observed UI controls or screenshot coordinates to drive an app, returning updated state and a new screenshot for coordinate actions.

Instructions

Click an observed control, including buttons and checkboxes, or a fresh screenshot coordinate. In a locked Windows agent desktop, use a single left indexed click without modifiers or duration. Returns updated state: indexed clicks return text; coordinate clicks also return a new screenshot for the next action. On macOS, clicking a menu bar item or submenu lists its items without displaying a menu; clicking a listed menu item runs its command.

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>"
    },
    "name": "click"
  }
}

Input Schema

NameRequiredDescriptionDefault
xNoX pixel coordinate in the most recently returned app-window screenshot; requires a screenshot after the last UI action.
yNoY pixel coordinate in that same app-window screenshot.
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
keyNoModifier chord held during the click, such as Shift or super.
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.
durationNoSeconds to hold before releasing, from 0 to 30. Windows press_key defaults to 0.05 seconds when omitted; explicit 0 remains allowed.
click_countNo
mouse_buttonNo
element_indexNoElement index from the latest returned app state

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.9.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true, so the return-state disclosure is genuinely additive: indexed clicks 'return text', coordinate clicks additionally return 'a new screenshot for the next action'. It also flags the macOS quirk that clicking a menu bar item lists items 'without displaying a menu', which prevents a wrong mental model of the side effect.

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?

Four tightly packed sentences with the core action front-loaded and no filler; platform-specific caveats come after the main behavior. Density is on the high side, but each sentence carries distinct operational 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 nine-parameter mutation tool with no output schema, the description covers return values and key platform constraints, which is more than most definitions do. Remaining gaps are the ambiguity between scope and element_index and the absence of any error or failure behavior.

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 78%, so the baseline is 3, and the description adds only modest meaning on top. It introduces the indexed-vs-coordinate distinction but never resolves which of the two index parameters (scope or element_index) 'indexed click' refers to, and it mentions modifiers/duration only as items to omit on locked desktops rather than explaining their effect.

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 specific verb and target set ('Click an observed control... or a fresh screenshot coordinate'), explicitly covering both indexed-element and raw-coordinate invocation modes. This lets an agent distinguish it immediately from siblings such as press_key, drag, and select_text.

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 context for variants: on a locked Windows agent desktop use 'a single left indexed click without modifiers or duration', and on macOS menu bar items the first click only expands the list while a second click on a listed item executes. It never states when to prefer a sibling like press_key or perform_secondary_action instead, so it falls short of full when/when-not guidance.

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