Skip to main content
Glama
xav-ie

Browser Session MCP

click

Destructive

Perform real CDP mouse presses in the active browser tab via CSS selector or viewport coordinates, enabling trusted handlers, popups, and form actions that synthetic JavaScript events can miss.

Instructions

Click in the session's active tab with real CDP mouse input (trusted events — fires handlers reliably and grants user activation, so it can open popups/new tabs that a JS click can't). Pass a CSS selector to click the first match's center, after waiting up to timeout for it and scrolling it into view; or pass both x and y to click viewport coordinates, which are used only when there is no selector. Don't use evaluate to click: synthetic JS clicks can be ignored by pages. Coordinates outside the viewport are not rejected; the click lands on nothing. A click can submit forms or trigger purchases, like a real user's. Returns a confirmation naming what was clicked. Fails if the selector matches nothing within timeout, or if neither a selector nor both coordinates are given.

Input Schema

NameRequiredDescriptionDefault
xNoHorizontal viewport coordinate in CSS pixels, used with `y` when no selector is given.
yNoVertical viewport coordinate in CSS pixels, used with `x` when no selector is given.
timeoutNoMilliseconds to wait for `selector` to appear. Default 5000.
selectorNoCSS selector of the element to click; the first match is used.
sessionIdYesThe id returned by open_browser_session. Errors if no open session has it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / selector / description
      Added value: +"CSS selector of the element to click; the first match is used."
    • addedInput schema / properties / sessionId / description
      Added value: +"The id returned by open_browser_session. Errors if no open session has it."
    • addedInput schema / properties / timeout / description
      Added value: +"Milliseconds to wait for `selector` to appear. Default 5000."
    • addedInput schema / properties / x / description
      Added value: +"Horizontal viewport coordinate in CSS pixels, used with `y` when no selector is given."
    • addedInput schema / properties / y / description
      Added value: +"Vertical viewport coordinate in CSS pixels, used with `x` when no selector is given."
  2. First observedv0.1.2

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already flag destructive/openWorld/non-idempotent, but the description adds substantial context: trusted events grant user activation, popups/new tabs may open, clicks can submit forms or trigger purchases, and out-of-viewport coordinates silently land on nothing. It also notes the returned confirmation and failure modes. This is rich beyond the annotations; only return-format detail is thin (no output schema exists).

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?

Dense and front-loaded, leading with the core action and trusted-event value proposition before usage modes and cautions. A single long paragraph rather than structured bullets, but nearly every sentence carries actionable information.

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?

With no output schema, the description still states that it returns a confirmation naming what was clicked, and it covers failure modes, side effects, and parameter interplay. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so all five params are documented, but the description adds real meaning: the selector/coordinate precedence, that timeout waits for the selector and scrolls it into view, and that missing/invalid combinations cause failure. This goes beyond the schema's per-field text.

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?

States a specific verb and resource ('Click in the session's active tab with real CDP mouse input') and immediately distinguishes its behavior from a JS/evaluate click. An agent can tell exactly what this tool does and how it differs from the sibling `evaluate`.

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

Usage Guidelines5/5

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

Explicitly prescribes the two usage modes (selector vs. x/y coordinates), states the precedence rule ('coordinates are used only when there is no selector'), gives an explicit when-not ('Don't use evaluate to click'), and names the failure conditions.

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