Skip to main content
Glama
This connector has been deprecated

Click element

browser_click
Destructive

Click a semantic element from the latest observation. Required: sessionId, observationId, elementId (the element's id from browser_observe). Optional button: left (default), middle, or right (contextmenu). Uses the DOM click() path; events are not isTrusted. File pickers and similar APIs return ELEMENT_NOT_INTERACTABLE — the human must click. If the click opens a JavaScript alert, confirm, or prompt, it returns promptly with dialog: { type, message, pending: true } and the dialog stays open until browser_handle_dialog or the 30s timeout. Another click, type, or navigation while it is open returns DIALOG_PENDING. A successful click, type, select, press_key, scroll, or navigate invalidates that observationId; reuse returns STALE_OBSERVATION — observe again. A second action on the same session waits up to 5s for the first to finish, then runs. That wait is a per-session FIFO stored with the session, so it still holds when calls land on different server instances. If that wait times out, the call returns BUSY with retryAfterMs. STALE_OBSERVATION means the page changed — observe again. Do not omit observationId. Clicks are paced; RATE_LIMITED means wait retryAfterMs. On a sensitive site the click waits for human Approve in the extension (APPROVAL_REQUIRED, recoverable). Approve runs that click once. Deny is APPROVAL_DENIED (not recoverable). While that action is waiting, observe/screenshot/wait/get_status/release_control and other same-origin actions on allowed origins still work; retrying the same pending action returns APPROVAL_PENDING. Cancel with browser_cancel_approval. Pending approvals expire after ~2 minutes (APPROVAL_EXPIRED). That wait is not CHALLENGE_DETECTED. Do not retry through CHALLENGE_DETECTED.

Input Schema

NameRequiredDescriptionDefault
buttonNo
elementIdYes
sessionIdYes
observationIdYes
idempotencyKeyNoA key replays the original result only within ~60 seconds of the first call, only for the same Mcp-Session-Id, the same credential (API key or OAuth token), the same browser session, and the same tool. After the window, or under a different session/credential/tool, the call executes and bills normally. Reusing a key with different arguments returns IDEMPOTENCY_KEY_REUSED and is not executed or billed. Refusals (e.g. NO_HISTORY_ENTRY) are not cached, so the same key re-executes once state changes. A key passed in _meta is ignored.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that events are not isTrusted, per-session FIFO serialization (5s wait) that holds across server instances, click pacing with RATE_LIMITED, approval flow with expiration and recoverability semantics, and the 30s dialog timeout. This is unusually rich behavioral context for a mutation tool.

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

Conciseness3/5

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

The first sentence is front-loaded and the rest is a single undifferentiated block of error-code prose with repeated content ('STALE_OBSERVATION means the page changed — observe again' appears twice, and 'Do not omit observationId' duplicates the required-field list). Bullets or grouping by error family would make it far easier to scan.

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 destructive, non-idempotent click there is no output schema, yet the description covers error semantics, concurrency, dialog state, approvals, and rate limiting — everything an agent needs to call it correctly and recover from failures.

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 only 20%, and the description compensates by explaining that elementId comes from browser_observe, that observationId is the observation token and must not be omitted, and that button maps left/middle/right with right meaning contextmenu. idempotencyKey semantics live in the schema, so nothing critical is lost, but sessionId is never characterized.

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 a semantic element from the latest observation') and ties the element to browser_observe via elementId, which separates it from siblings like browser_hover or browser_type. An agent can tell exactly what this tool does without opening the schema.

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 routes to alternatives and follow-ups: re-observe after STALE_OBSERVATION, use browser_handle_dialog for open dialogs, browser_cancel_approval to cancel approvals, and the human must click file pickers. It also states what not to do ('Do not retry through CHALLENGE_DETECTED').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources