Skip to main content
Glama
DB-25

arc-control-mcp

by DB-25
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Wait For Selector

wait_for_selector
Read-onlyIdempotent

Poll until an element appears, becomes visible, or disappears after a click loads content. Returns explicit counts on timeout and fails fast on broken selectors or page errors.

Instructions

Poll until an element appears, becomes visible, or disappears. Use after a click that loads content. On timeout it says so explicitly with waitedMs and the last counts, and a broken selector or page error fails straight away instead of burning the whole timeout. The visible state ignores screen-reader clipping (boxes under 2x2 px, inset clip-path), which nothing can actually click.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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.
stateNoCondition to wait for. A ref that is gone counts as absent.visible
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"
timeout_msNoGive up after this long. Every call returns the current counts, so repeated short waits tell you more than one long one. Capped at 30000ms so the call cannot outlive a client's request timeout. To wait longer, call this again.

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 / 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\""
    • changedInput schema / properties / state / description
      Previous value: -"Condition to wait for"New value: +"Condition to wait for. A ref that is gone counts as absent."
    • 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."
    • changedInput schema / properties / timeout_ms / description
      Previous value: -"Give up after this long, capped at 30000ms because a longer call is killed by the client before it can answer. To wait longer, call wait_for_selector again: every call returns the current counts, so repeated short waits tell you more than one long one."New value: +"Give up after this long. Every call returns the current counts, so repeated short waits tell you more than one long one. Capped at 30000ms so the call cannot outlive a client's request timeout. To wait longer, call this again."
  2. First observedv0.3.0

TDQS

A4.1/5.0
Behavior5/5

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

Adds substantial behavior beyond the readOnly/idempotent annotations: explicit timeout behavior (returns waitedMs and last counts), fast-fail on broken selector or page error instead of burning the timeout, and a precise definition of 'visible' that ignores screen-reader clipping (boxes under 2x2 px, inset clip-path). These are real operational traits an agent could not infer from structured fields.

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 core action, then the usage cue, then failure-mode and visibility nuance. Every sentence carries information; the density is high but not padded.

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

Completeness4/5

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

With no output schema, the description compensates by describing what a timeout returns (waitedMs, counts) and how errors surface. Combined with 100% schema coverage and readOnly annotations, an agent has enough to call it correctly; only explicit sibling disambiguation is missing.

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 parameters (state, exact, tab_id, verbose, selector, timeout_ms) are already fully documented in the schema. The description adds only marginal semantics, such as reiterating timeout behavior; baseline 3 is appropriate when the schema carries the load.

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?

States a specific verb and resource: 'Poll until an element appears, becomes visible, or disappears.' This distinguishes it from pure load-waiting tools, though it never names sibling alternatives like wait_for_text or wait_for_load that an agent might confuse it with.

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 situational context—'Use after a click that loads content'—which tells the agent the triggering scenario. It stops short of naming alternatives or when-not-to-use conditions, but the usage context is unambiguous.

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