Skip to main content
Glama

browser_click

Click an element on the page. Supports CSS selectors AND text-based selectors. Auto-scrolls element into view. Uses real mouse events (works on Angular/React SPAs and CSP-strict sites like Google, Stripe).

Instructions

Click an element on the page. Supports CSS selectors AND text-based selectors. Auto-scrolls element into view. Uses real mouse events (works on Angular/React SPAs and CSP-strict sites like Google, Stripe). A text selector looks inside an open modal dialog first (a opened with showModal, or a visible element with aria-modal="true"), exact text before partial. If the mouse would not reach the target at its center - another element lies in front of it (an overlay, a dialog's backdrop), the target does not take clicks there (pointer-events, visibility, clipping), or a different control inside it would get the click (a delete button on a card; for a container that is not clickable itself, its own plain link with a real address (a hash route with a path, such as #/orders, counts; a fragment with no target on the page does not) does not count, nor does a web component's own button that covers it, nor a box with a checkbox, switch or radio role right next to a hidden field and the only one in the nearest label around it, a label of that field (a box inside a closed shadow root cannot be seen and is not counted), which counts as that field) - the answer is ok:false with error "covered" and covered_by. Found before the mouse is sent, nothing is sent; if it comes in front afterwards, the rest of the presses and clicks are stopped (a release the page moves elsewhere is let through), and the answer also has maybe_landed: true, because the page may already have reacted. Examples: "button:text(Get started)", "text=Submit", "#my-button", "a.btn-primary"

Input Schema

NameRequiredDescriptionDefault
selectorYesCSS selector or text selector. Text formats: "text=Click me" (any element), "button:text(Submit)" (specific tag)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and delivers: auto-scroll into view, real mouse events that work on SPA/CSP-strict sites, modal-dialog-first text resolution, and a detailed failure contract (ok:false, error 'covered', covered_by, maybe_landed). This is unusually rich disclosure of behavior an agent cannot infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening is front-loaded and crisp, but the 'covered' sentence is a single sprawling construction with deeply nested parentheticals ('...nor does a web component's own button...nor a box with a checkbox, switch or radio role right next to a hidden field...') that is very hard to parse. The information is valuable but the packaging is bloated and structurally poor.

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?

No output schema exists, so the description must and does explain the failure return shape ('covered', covered_by, maybe_landed). For a single-parameter click tool this is close to complete; only the success-path response and any waiting/timing semantics are unspecified, which are minor gaps.

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?

Schema description coverage is 100%, so the baseline is 3. The description exceeds that by enumerating concrete selector formats and giving four worked examples ('#my-button', 'text=Submit', etc.), plus documenting the modal-first text-matching order — meaning well beyond the schema's terse parameter note.

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?

Opens with a specific verb and resource ('Click an element on the page') and immediately clarifies the selector model, which distinguishes it from pointer-coordinate siblings like browser_click_xy. It never names the sibling alternatives (browser_double_click, browser_right_click), so the differentiation is implicit rather than stated.

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?

Offers rich tactical guidance on selector choice (CSS vs text, 'text=Submit' vs 'button:text(Submit)') and modal-priority resolution, which implicitly tells the agent how to invoke it. However, it never states when to choose this tool over browser_click_xy, browser_double_click, or browser_right_click, so alternative-selection guidance is absent.

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