Skip to main content
Glama
Gwakko

agent-in-browser

by Gwakko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

click

Simulate trusted mouse events on links, buttons, checkboxes, or custom widgets by ref, CSS selector, visible text, or x/y point; returns what was activated plus any new page title and URL.

Instructions

Click an element, chosen by ref, CSS selector or visible text, or a viewport point x,y, using real trusted mouse events (so it works on links, buttons, custom widgets and checkboxes). The element is scrolled into view first. Returns what was clicked (and warns if another element covers it); if the click navigated, it waits for the new page and reports its title and URL. Refs may be stale after navigation, so snapshot again. Use hover to move without clicking, fill_form for form fields.

Input Schema

NameRequiredDescriptionDefault
xNoViewport x coordinate in CSS px, used instead of an element.
yNoViewport y coordinate in CSS px.
refNoElement ref from the latest snapshot or find, e.g. "e12". Preferred: unambiguous and fastest; stale after navigation.
tabNoTab id from tabs_list. Defaults to the current tab.
matchNoVisible text or accessible name to match (case-insensitive substring), e.g. "Sign up"; use when you have no ref.
buttonNoMouse button (default left).
doubleNoDouble-click instead of a single click (default false).
selectorNoCSS selector; the first matching element is used.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.2
    • changedInput schema / properties / double / description
      Previous value: -"Double-click."New value: +"Double-click instead of a single click (default false)."
    • changedInput schema / properties / match / description
      Previous value: -"Visible text / accessible name to match (case-insensitive substring)."New value: +"Visible text or accessible name to match (case-insensitive substring), e.g. \"Sign up\"; use when you have no ref."
    • changedInput schema / properties / ref / description
      Previous value: -"Element ref from snapshot/find, e.g. \"e12\". Preferred."New value: +"Element ref from the latest snapshot or find, e.g. \"e12\". Preferred: unambiguous and fastest; stale after navigation."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector (first match)."New value: +"CSS selector; the first matching element is used."
    • changedInput schema / properties / x / description
      Previous value: -"Viewport x coordinate (instead of an element)."New value: +"Viewport x coordinate in CSS px, used instead of an element."
    • changedInput schema / properties / y / description
      Previous value: -"Viewport y coordinate."New value: +"Viewport y coordinate in CSS px."
  2. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and openWorldHint=true; the description goes well beyond by disclosing the scroll-into-view side effect, the coverage warning, the navigation wait with title/URL reporting, and ref staleness after navigation. These are exactly the operational traits an agent needs before invoking a page-mutating click.

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?

Front-loaded with the action and supported addressing modes, then consequences, then alternatives — a good information order. It is five dense sentences and slightly long, but no sentence is filler; the only redundancy is restating addressing modes already in the schema.

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 the return payload (what was clicked, coverage warning, navigated title/URL). Combined with 8 optional params, the staleness caveat, and the named alternatives, an agent has everything needed to call it correctly and interpret results.

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?

With 100% schema description coverage, the schema already documents all 8 parameters including ref preference and x/y-as-alternative. The description restates the addressing modes (ref, CSS selector, visible text, x/y) but adds no syntax, precedence rules, or conflict resolution beyond what the schema says; baseline 3 applies.

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 (click) and resource (element, addressed by ref/selector/text/coordinates) and immediately names the mechanism (real trusted mouse events) and its consequence (works on links, buttons, custom widgets, checkboxes). This is clearly differentiated from siblings like hover, fill_form, and 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 routes the agent: 'Use hover to move without clicking, fill_form for form fields,' and the schema-preferred ref path is reinforced in prose. It also gives a follow-up rule — 'Refs may be stale after navigation, so snapshot again' — which is a when-to-do-what-else instruction, not just a fact.

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