Skip to main content
Glama

tool_click_at

Click a point in a window's client area by UI Automation element when possible, falling back to a verified raw cursor click; dry run checks the target without input.

Instructions

Click at client-area coordinates within a window. Coordinates relative to window content area (0,0 = top-left). Tries the ELEMENT path first (resolve the point via UI Automation and invoke that element) because it needs no focus and does not care about z-order; falls back to a raw cursor click, which does. The result's method says which was used: 'ax_press' or 'raw_event'. MUTATING: serialized across agent sessions; the raw_event path ALSO YIELDS TO THE USER (waits for input-quiet, then refuses with user-active rather than fighting them for the cursor); the ax_press path injects no physical input. The raw path verifies the addressed window actually owns that screen point and returns success=false instead of clicking another window. Pass dry_run=true to check where the click would land without moving the cursor, clicking, or taking any gate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
hwndNo
titleNo
preferNoelement
dry_runNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.9/5.0
Behavior5/5

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

No annotations are present, so the description carries the full burden. It discloses mutation, serialization, user yielding for the raw path, z-order/focus dependencies, window ownership verification, and dry_run side-effect-free behavior. This is unusually rich and goes well beyond a simple 'click'.

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 long but front-loaded with the core purpose and every sentence adds a distinct behavioral fact. The MUTATING and dry_run sentences are dense but necessary; could be slightly tightened but overall well structured.

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 a 6-param tool with no annotations and no schema descriptions, the description covers most behavioral context but leaves title and full prefer semantics undocumented. It is close to complete but not fully sufficient for all invocation decisions.

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?

With 0% schema coverage, the description must document parameters. It explains x/y are client-area coordinates, dry_run prevents effects, prefer relates to element vs raw, and hwnd as 'addressed window'. Title is not documented, and prefer values beyond default 'element' are unstated, so compensation is strong but incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Click at client-area coordinates within a window') and gives coordinate meaning. It explains internal click paths but does not explicitly differentiate from sibling tools like tool_element_action_at or tool_send_keys, so it lacks direct sibling contrast.

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 explains how the tool behaves (element first, raw fallback, dry_run) and when it is safe to use, but it never tells the agent which sibling to choose instead. No exclusions or comparisons to alternatives are given, so usage guidance is implied by the action itself.

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