Skip to main content
Glama

pointer_click

Click at a screen position and verify the outcome: detects whether the click landed on a UI element or dead space, shows the affected window only when something changes, and can refuse the click if another window occludes the target.

Instructions

Click at an absolute screen position. Reports whether it LANDED on anything -- the screen is compared before and after, so a click into dead space says so instead of looking exactly like one that worked -- and shows you the result without a separate screenshot. Also reports whether the keyboard moved as a result. PASS expect_window: the click is refused if something else is under that point, which is the difference between a missed click and a click in someone else's window. Needs no consent dialog, unlike xdotool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
refNoA widget number from the last screen_map -- the click lands at that widget's CURRENT position after its identity is re-verified, no coordinates needed. Give ref OR x/y, never both. Refs die at the next screen_map call.
lookNoWhat to show you afterwards. Default "auto": wait for the screen to stop changing, measure how much this action changed, and attach a picture of the affected window only if something did change -- so a click that hit nothing costs no tokens and says so. "window" always attaches it, "screen" uses the whole desktop (slower, 6x the tokens), "region" uses look_at, false skips all of it. Use false for the middle of a sequence you are going to check at the end anyway.auto
countNo2 for a double click.
buttonNoleft
look_atNoRectangle for look:"region", in screen pixels. Object form {x, y, width, height} or array form [x, y, width, height].
hover_firstNoApproach the point and settle before clicking, so a toolkit that only arms a button on hover gets its motion event. Chromium/CEF/Electron buttons (Creative Cloud, Spotify, 'desktop web' apps) commonly ignore a bare click and report nothing changed. Costs ~0.25s.
on_occludedNoWhat to do when expect_window is not the window at that point. Default refuses and names the blocker with its id and geometry. "click_topmost" clicks whatever is in front instead, in this same call, and says which window received it -- for a dialog that spawned over the button you were aiming at.refuse
settle_max_sNoHow long to wait for the screen to stop changing before looking. Raise it for an app that animates slowly; set it to 0 to capture immediately.
expect_windowNoThe window this click is aimed at (id, wm_class or title fragment). Nothing is clicked if it is not the window at that point.
Install Server

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It does well by explaining that the screen is compared before and after, that clicks into dead space are reported as such, that the result is shown without a separate screenshot, and that keyboard movement is reported. It also discloses the refusal behavior when expect_window is not matched. It does not fully specify side effects or exact response shape, but it covers the key behavior strongly.

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 front-loaded with the core action and includes several valuable behavioral notes without being bloated. It is slightly conversational and could be tightened, but every sentence contributes useful information about what the tool does and how to use it safely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with no output schema and no annotations, the description gives important behavioral context but does not fully cover the tool's usage space. It explains click landing, expect_window, and result presentation, but does not address choosing between ref and x/y, the meaning of other parameters, or the exact structure of the returned result. The rich schema descriptions compensate partially, leaving the description adequate but not complete.

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 73%, so the schema already documents most parameters. The description adds meaningful nuance for expect_window, explaining the difference between a missed click and clicking in someone else's window, but it does not add extra semantics for the other parameters, such as ref, button, count, or look_at. Overall it provides modest added value over 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?

The description opens with a specific verb and resource: 'Click at an absolute screen position.' This clearly distinguishes the tool from siblings like pointer_move, pointer_drag, and pointer_scroll by establishing that it performs a click and reports outcomes. The additional details about landing detection and expect_window further clarify its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful context, especially 'PASS expect_window' to avoid clicking in the wrong window, and notes it needs no consent dialog unlike xdotool. However, it does not explicitly say when to use pointer_click versus sibling input tools like pointer_move or pointer_drag, so usage guidance is implied rather than fully articulated.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tristanmuzzu/deskwright'

If you have feedback or need assistance with the MCP directory API, please join our Discord server