seleniumbase-mcp

Official

Overview Schema Source Related Servers Discussions Admin

wait_for_condition

Block automation until a page element is present, visible, hidden, or gone, or for a set number of seconds, so dynamic pages finish loading before the next step.

Instructions

Wait for a page condition or for a specified duration.

Use this for synchronization when a dynamic page may need time to reach a condition before the next automation step. The tool blocks until the condition is met or the timeout expires. It does not intentionally scroll, click, or otherwise modify the page while waiting.

Use check_if_condition to inspect the current state without waiting. Use assert_condition to verify an expected condition rather than synchronize with a changing page.

When the condition is not reached before timeout, the underlying SeleniumBase wait failure is handled by the tool's error handler rather than returning a success confirmation.

If state="seconds_passed", selector and text are ignored and the tool blocks for the full timeout seconds.

If text is supplied, present/visible wait for the text to appear, while absent/not_visible wait for the text to disappear. If no selector is supplied, text is searched within the page body.

Args: state: - "present": Wait until the matching element exists. - "visible": Wait until the matching element is visible. - "not_visible": Wait until the matching element is not visible. - "absent": Wait until the matching element no longer exists. - "seconds_passed": Wait for the full timeout duration.

selector: CSS or SeleniumBase selector for the element.
    Required unless `text` is supplied or `state="seconds_passed"`.

text: Optional text to wait for or wait to disappear.
    With text, `present` and `visible` are equivalent,
    as are `absent` and `not_visible`.

timeout: Maximum seconds to wait for the condition;
    for `seconds_passed`, the exact duration to wait. Must be >= 0.

Returns: A success message when the requested condition is reached. If the condition times out or the underlying wait fails, the tool returns the error produced by its error handler.

Tool selection: - Inspect current state immediately -> check_if_condition. - Wait for a state change -> wait_for_condition. - Verify an expectation -> assert_condition.

Input Schema

TableJSON Schema

Name	Required	Default
`text`	No
`state`	No	visible
`timeout`	No
`selector`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.3.4Sep 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares the call blocks, that it does not scroll/click/modify the page, and that a timeout surfaces as an error-handler failure rather than a success confirmation. It also flags the interaction rules between text, selector, and seconds_passed, which materially changes behavior.

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 behavior and organized under Args/Returns/Tool selection headings. It is longer than strictly necessary because the final 'Tool selection' block restates routing advice already given in the opening paragraphs, creating mild redundancy.

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 blocking-wait tool with four parameters, an enum, and an output schema, the description covers side effects, failure semantics, parameter interdependencies, and sibling routing. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate and it does: it enumerates every state enum value with its meaning, states selector's requirement condition, explains that text makes present/visible and absent/not_visible equivalent, and gives timeout's dual meaning (max wait vs. exact duration).

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 action (block until a page condition or duration elapses) with clear scope, and explicitly distinguishes itself from the two nearest siblings, check_if_condition and assert_condition, by naming what each does instead. An agent can route correctly without opening any schema.

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?

Gives explicit when-to-use ('synchronization when a dynamic page may need time to reach a condition') plus a three-way selection guide: inspect now -> check_if_condition, wait for change -> wait_for_condition, verify expectation -> assert_condition. Exclusions are stated, not inferred.

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