Skip to main content
Glama

Click

browser_click

Clicks a referenced page element with real mouse events, waits for navigation, and reports blocking elements or new tabs so you can verify the action.

Instructions

Clicks a ref element with real mouse events. If another element covers it, doesn't click and reports it. Waits for loading if the click navigates; reports new tabs. Clicking a file input or "attach" button intercepts the OS file picker (not shown); then use browser_upload. Doesn't click dropdowns (they open a list popup on the user's screen); use browser_select.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slot": "<slot>",
      "ref": "<ref>"
    },
    "name": "browser_click"
  }
}

Input Schema

NameRequiredDescriptionDefault
refYesref from browser_snapshot (e.g. "e12")
tabNoTarget tab: number (1, 2…) or ID ("t7"). Use the stable ID when agents share a slot. Required for action tools when there are multiple tabs.
readNoAppend the page after the action (no separate read needed): text=body text, snapshot=snapshot page 1 (with refs), changes=only lines added/removed since your last snapshot (shortest; full page if the page changed)
slotYesBrowser slot 1-30. "3", "slot 3", "browser 3" → 3. If the user gives a port like 14052, subtract 14049.
agentNoYour display name, shown to other agents. Subagents must always set it. Default "claude-1e1b".
doubleNoDouble-click
summaryNoOne-line note of what you are doing (e.g. "comparing laptop prices"). Shown in browser_status (not the status line). Omit to keep the previous one.
multiSlotNotrue only when one agent must handle several slots together (e.g. comparing). Normally omit (one agent = one slot; use subagents for the rest)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.10
    • changedInput schema / properties / agent / description
      Previous value: -"Your display name, shown to other agents. Subagents must always set it. Default \"claude-68d9\"."New value: +"Your display name, shown to other agents. Subagents must always set it. Default \"claude-1e1b\"."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and meets it: it discloses occlusion handling (no click, reports the covering element), navigation wait behavior, new-tab reporting, and OS file-picker interception semantics. These are non-obvious runtime traits that go well beyond a generic 'click' contract.

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

Conciseness5/5

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

Five short sentences, each adding a distinct operational fact, with the core action front-loaded ahead of the edge cases. There is no filler, restatement of the title, or redundant phrasing.

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?

No output schema exists, and the description compensates by describing what the click returns/reports (occlusion report, navigation completion, new tab). Combined with a fully documented parameter schema, an agent has everything needed to invoke and interpret this tool.

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

Parameters3/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 only indirectly touches the ref parameter ('ref element') and says nothing about double, tab, read, slot, or agent semantics beyond what the schema already documents.

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 — clicking a ref-addressed element with real mouse events — and immediately scopes it against sibling actions (browser_upload, browser_select). An agent can distinguish it from browser_type, browser_fill, and browser_hover without opening any 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?

Gives explicit when-not rules with named alternatives: file inputs and 'attach' buttons route to browser_upload, and <select> dropdowns route to browser_select. The conditions that select those alternatives are spelled out, which is exactly what an agent needs to route correctly.

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