Skip to main content
Glama

glass_click_element

Click a UI element by its accessibility snapshot ID, using the platform's native action when available. Falls back to a synthetic pointer click if needed, and handles occluded or off-screen elements automatically.

Instructions

Click an element by its #id from glass_a11y_snapshot (actuates via the platform's native accessibility action when the element exposes one — works even when it's occluded or scrolled off-screen — else falls back to a synthetic pointer click at the center of its bounds; the result's method field says which path ran, native_fallback says why when the pointer path was used, and actuated_id names the element actually clicked when a control's label is a separate element from the control itself). If the element actually renders in a popover owned by a different window than the active one (e.g. an open dropdown's option row), the click is automatically routed into that popover window and the previously-active window is restored afterward. Ids are only valid within the latest snapshot — re-run glass_a11y_snapshot if the UI changed. Optional return: "snapshot" settles the UI then folds a fresh a11y tree into the result (and refreshes the snapshot cache); "settle" waits for the UI to stop changing (text-only); omit or "none" for no observe (default).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe element `#id` from `glass_a11y_snapshot`. Valid only within the latest snapshot — re-snapshot if the UI changed. If the element actually renders in a popover owned by a different window than the active one (e.g. an open dropdown's option row), the click is automatically routed into that popover window and the previously-active window is restored afterward — no extra step needed. Clicks via the platform's native accessibility action when the element exposes one (works even when the element is occluded or scrolled off-screen), falling back to a synthetic pointer click at the element's center; the result's `method` field says which path ran, and `native_fallback` says why when the pointer path was used. Where a control's label is a separate element from the control itself, the native action fires on the enclosing control and the result carries `actuated_id` — the element actually clicked.
returnNoOptional observe folded into the result: "snapshot" (wait for the UI to settle, then fold a fresh a11y tree, also refreshing the snapshot cache), "settle" (wait for the UI to stop changing, text-only), or "none" (default).
Behavior5/5

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

The description thoroughly discloses side effects and nuances: it can click occluded/off-screen elements via the native action, falls back to pointer click, routes clicks into popover windows, and restores the previous window. It explains result fields and id validity. Annotations (`readOnlyHint=false`, `destructiveHint=false`) align with a click action that is not read-only but not destructive. No contradictions.

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 dense; every clause adds functional detail. It front-loads the primary action and then layers edge cases and result semantics. While a bit verbose, it avoids redundancy and is organized logically (method, fallback, routing, id validity, return options).

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 complex behavior and no output schema, the description covers all critical aspects: actuation paths, fallback reasons, popover routing, id freshness, return options, and result fields. An agent has enough to call it correctly and interpret results without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed parameter descriptions, and the description goes further: it explains id scoping to the latest snapshot, popover routing, the `return` parameter's effects (refreshing cache, settling), and the meaning of result fields. This adds substantial value beyond the raw 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 specifies the exact action: clicking an element by its a11y snapshot id, and explains the two actuation paths (native accessibility action vs synthetic pointer click) and the result fields (`method`, `native_fallback`, `actuated_id`). It clearly differentiates this from coordinate-based clicking (sibling `glass_click`) by anchoring to snapshot ids.

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?

It states the prerequisite clearly: you need an id from `glass_a11y_snapshot`, and re-runs the snapshot if the UI changed. It also covers the popover routing case and the optional `return` modes. However, it does not explicitly contrast with alternatives (e.g., `glass_click` for coordinates or `glass_set_value` for text) — though the context implies when to use it.

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

Install Server

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/fixed-width/glass'

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