Skip to main content
Glama
DB-25

arc-control-mcp

by DB-25
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Click

click

Dispatch a real pointer sequence on a page element selected by CSS, text, ref, role, label, or placeholder; scrolls into view so framework handlers fire.

Instructions

Click an element. Accepts a CSS selector or "text=Label". Scrolls it into view and dispatches a real pointer sequence, so framework handlers fire. "text=Label" matches on visible text as a substring, with exact matches ranked first and visible elements ahead of hidden ones, so a short label also matches longer ones. Check the returned "matches" count, and pass exact when it is above 1. Also accepts "ref=e12" from snapshot (re-resolved and reported as reResolved when the page re-rendered, a clear stale-ref failure when the element is truly gone), "role=button[name="Save"]", "label=Email" and "placeholder=Search". Returns urlBefore, the url as it was immediately before the click: the tab snapshot can be taken before a navigation settles, so follow with wait_for_load when the click navigates. A match inside a control (a label span in a button) is checked against that control, returned as "control": a disabled one fails with ok false and nothing is clicked. When another element (a modal backdrop, an overlay) covers the target, or it has pointer-events none, the click still goes through but the result carries coveredBy and a warning. On success it waits for the page to go quiet and reports settledMs (and settled false if the DOM was still changing at the cap), so the next read sees the result of the action.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nthNoWhich match to click when several exist, 0-based. For text= selectors the order is exact matches first, then substring matches, visible before hidden within each, then DOM order.
exactNoFor "text=", "label=" and "placeholder=" selectors, require the whole trimmed text to equal the label instead of containing it. No effect on CSS, ref= or role= selectors.
tab_idNoArc tab id from list_tabs. Omit to use this agent's current tab. A tool that changes a tab will not fall back to the tab the user is looking at, so pass this or call open_url first.
verboseNoInclude the bulky element rect and longer attribute values
selectorYesCSS selector, or one of: "text=Some label" (visible text, case-insensitive substring, exact matches ranked first); "ref=e12" (a ref from snapshot, re-resolved if the page re-rendered); "role=button[name="Save"]" (ARIA or implicit role, name an exact match, or name~="sav" for a substring); "label=Email" (the control a label names); "placeholder=Search"
settle_msNoAfter acting, wait until the page's DOM has been quiet for this many ms, then report settledMs. 0 skips the wait. The whole wait is capped at 1500ms; a page that never goes quiet reports settled false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.4.0
    • changedInput schema / properties / exact / description
      Previous value: -"For \"text=\" selectors, require the whole trimmed text to equal the label instead of containing it. No effect on CSS selectors."New value: +"For \"text=\", \"label=\" and \"placeholder=\" selectors, require the whole trimmed text to equal the label instead of containing it. No effect on CSS, ref= or role= selectors."
    • changedInput schema / properties / nth / description
      Previous value: -"Which match to click when several exist, 0-based. Order is exact text matches first, then substring matches, each in DOM order."New value: +"Which match to click when several exist, 0-based. For text= selectors the order is exact matches first, then substring matches, visible before hidden within each, then DOM order."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector, or \"text=Some label\" to match on visible text (substring, exact matches ranked first)"New value: +"CSS selector, or one of: \"text=Some label\" (visible text, case-insensitive substring, exact matches ranked first); \"ref=e12\" (a ref from snapshot, re-resolved if the page re-rendered); \"role=button[name=\"Save\"]\" (ARIA or implicit role, name an exact match, or name~=\"sav\" for a substring); \"label=Email\" (the control a label names); \"placeholder=Search\""
    • addedInput schema / properties / settle_ms
      Added value: +{
+  "default": 300,
+  "description": "After acting, wait until the page's DOM has been quiet for this many ms, then report settledMs. 0 skips the wait. The whole wait is capped at 1500ms; a page that never goes quiet reports settled false.",
+  "maximum": 1500,
+  "minimum": 0,
+  "type": "number"
+}
    • changedInput schema / properties / tab_id / description
      Previous value: -"Arc tab id from list_tabs. Omit to use this agent's current tab, falling back to whatever tab is active in Arc."New value: +"Arc tab id from list_tabs. Omit to use this agent's current tab. A tool that changes a tab will not fall back to the tab the user is looking at, so pass this or call open_url first."
  2. First observedv0.3.0

TDQS

A4.6/5.0
Behavior5/5

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

Far beyond the annotations: modal backdrop/overlay coverage, disabled-control failure, pointer-events:none, stale ref re-resolution vs. failure, and post-click settle behavior are all disclosed. This is unusually rich for a click tool.

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-loads the core purpose in the first sentence and keeps each subsequent sentence on one topic, though the single long paragraph packs many distinct behaviors and could be split for scanability.

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 6-param, annotations-only tool with no output schema, the description covers matching semantics, tab-scoping, post-click settling, and failure modes. An agent has everything it needs to invoke correctly.

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 baseline is 3, but the description adds real value: it explains that a short text label also matches longer ones (substring semantics), which the nth/exact parameter descriptions only imply, and provides the 'check matches then pass exact' workflow.

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 ('an element'), then enumerates the accepted selector syntaxes, distinguishing it from trusted_click and hover in the sibling list.

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?

Gives clear context for when to pass tab_id, when to follow with wait_for_load, and when to pass exact (matches > 1). Does not explicitly contrast against trusted_click or its other siblings, which is the one miss.

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