Skip to main content
Glama
escapeWu

chrome-agent-bridge

by escapeWu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Click page element

browser_click

Clicks a web element by CSS selector in a Chrome tab for legacy workflows.

Instructions

Compatibility selector-based click. New workflows should use browser_snapshot refs with browser_act.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tabIdYes
browserNoWhich connected Chrome to use: an instanceId or label from browser_list_instances. Required when more than one browser is connected; session-based tools infer it from their sessionId.
selectorYes
confirmedNoSet true only after the user explicitly confirms a potentially submitting click.
debuggerSessionIdNoRaw or network session ID this task holds on the tab. Required when the tab has a live debugger lease; omit otherwise.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.10.0
    • addedInput schema / properties / debuggerSessionId
      Added value: +{
+  "description": "Raw or network session ID this task holds on the tab. Required when the tab has a live debugger lease; omit otherwise.",
+  "maxLength": 120,
+  "minLength": 20,
+  "type": "string"
+}
  2. Changed1 schema field changedv0.9.1
    • addedInput schema / properties / browser
      Added value: +{
+  "description": "Which connected Chrome to use: an instanceId or label from browser_list_instances. Required when more than one browser is connected; session-based tools infer it from their sessionId.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
  3. First observedv0.6.0

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the tool's compatibility/legacy status and the preferred alternative, but says nothing about click side effects — navigation, form submission, waiting for load, or failure modes — which matter for a mutating interaction.

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?

Two tight sentences, zero filler, with the compatibility caveat and the preferred alternative front-loaded. Nothing could be cut without losing routing value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutating click tool with no annotations and no output schema, the description covers tool selection well but is thin on what the click actually does (submission, navigation, confirmation requirements) and on restart/error behavior. The schema's 'confirmed' field partially compensates, keeping this at minimum-viable rather than inadequate.

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

Parameters2/5

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

At 60% schema coverage, tabId and selector are undocumented in both schema and description, and the description adds no parameter semantics at all. It does not explain that 'confirmed' gates potentially submitting clicks or how browser/debuggerSessionId selection interacts with this call.

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?

The phrase 'Compatibility selector-based click' gives a specific verb (click) and mechanism (CSS/selector targeting), and explicitly contrasts itself with browser_act's ref-based approach. It does not spell out the resource scope (a page element in a given tab), but an agent can identify the action 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 Guidelines4/5

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

Explicitly routes new workflows to 'browser_snapshot refs with browser_act', which is a clear when-not-this / use-that statement. It does not state the condition under which this tool is still the right choice (e.g., only selectors available, no snapshot refs), leaving that inference to the agent.

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

Deploy Server

Other Tools