Skip to main content
Glama
andresolbach

nodriver-mcp-server

by andresolbach
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Wait for element

wait_for_selector
Read-only

Wait for a CSS selector to appear on the page, checking repeatedly until the element exists. Ideal for known markup or localized text; then take a snapshot for interaction.

Instructions

Wait until an element matching a CSS selector appears on the page.

The structural counterpart to wait_for: use it when you know the markup but not the wording, or when the wording is localised.

Polls about three times a second and returns as soon as the element shows up. Unlike wait_for it does not return a snapshot, so follow with take_snapshot when you intend to interact.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
browserNoWhich browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.default
timeoutNoMaximum wait in milliseconds before giving up.
visibleNoAlso require the element to have a non-zero size. Use this with frameworks that insert an element into the DOM before rendering it — presence alone would otherwise resolve too early.
selectorYesCSS selector to wait for, e.g. "#login" or ".results .item".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • addedInput schema / properties / browser
      Added value: +{
+  "default": "default",
+  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
+  "type": "string"
+}
  2. First observedv1.7.2

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, the description discloses polling frequency ('about three times a second'), immediate return on element appearance, and the notable behavioral difference from wait_for: it does not return a snapshot. This adds valuable runtime behavior context that annotations cannot convey.

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 well-structured: a one-sentence definition, a usage condition, and a behavioral note with follow-up advice. Every sentence earns its place, with no filler or repetition of schema content.

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 wait-for tool with an output schema and detailed parameter descriptions, the description covers the key usage distinctions, behavioral characteristics, and necessary follow-up action. Nothing essential is missing for an agent to invoke it correctly.

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 the schema already documents all four parameters in detail. The tool description adds no additional parameter semantics, which is acceptable under the baseline of 3 when the schema carries the full burden.

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 clearly states a specific verb and resource: 'Wait until an element matching a CSS selector appears on the page.' It also distinguishes itself from the sibling wait_for by framing this as the 'structural counterpart,' so an agent can tell them apart immediately.

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?

Explicit guidance is provided: use this tool when the markup is known but wording is not, or when wording is localized. It names the alternative (wait_for) and even instructs to follow with take_snapshot for interaction, making the usage context 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