Skip to main content
Glama
DB-25

arc-control-mcp

Wait For Selector

wait_for_selector
Read-onlyIdempotent

Waits for an element to appear, become visible, or disappear, ideal after a click that loads content. Reports timeout with waitedMs 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=" selectors, require the whole trimmed text to equal the label instead of containing it. No effect on CSS selectors.
stateNoCondition to wait forvisible
tab_idNoArc tab id from list_tabs. Omit to use this agent's current tab, falling back to whatever tab is active in Arc.
verboseNoInclude the bulky element rect and longer attribute values
selectorYesCSS selector, or "text=Some label" to match on visible text (substring, exact matches ranked first)
timeout_msNoGive 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.
Install Server

TDQS

A4.7/5.0
Behavior5/5

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

The description goes well beyond the readOnly/openWorld/idempotent annotations by explaining timeout behavior (waitedMs and last counts), fast-failure on broken selectors/page errors, and the subtle visible-state handling of screen-reader clipping. These are valuable behavioral details an agent needs to interpret results correctly.

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?

The description is compact and front-loaded, with the purpose stated in the first sentence. Each subsequent sentence adds meaningful behavioral or edge-case information, with no filler or redundant restatement of the title.

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 tool with 6 parameters, no output schema, and rich annotations, the description is complete. It covers purpose, when to use it, failure modes, timeout semantics, and a subtle visibility edge case. The schema covers the remaining parameter-level details.

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 the baseline is 3. The description adds meaning beyond the schema by clarifying what 'visible' means in practice (clipping behavior) and how timeout_ms failure reporting works. This enriches the parameter semantics without repeating schema content.

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?

The description opens with a precise verb and resource: 'Poll until an element appears, becomes visible, or disappears.' This clearly differentiates it from sibling tools like wait_for_load or query_elements by focusing on selector-based state polling.

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?

The description gives a clear usage context: 'Use after a click that loads content.' It doesn't explicitly name alternatives or exclusions, but the guidance is specific enough for an agent to know when this polling tool is appropriate.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DB-25/arc-control-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server