SeleniumBase MCP

Official

Overview Schema Source Related Servers Discussions Admin

Wait For Condition

wait_for_condition

Read-onlyIdempotent

Wait until a page element is present, visible, absent, or not_visible, or until a specified duration passes. Blocks for synchronization, returning success or a timeout error.

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.

Addedv4.54.4Sep 13, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful detail: the tool blocks, does not scroll/click/modify, handles timeouts through an error handler, and treats seconds_passed as a pure delay. This goes well beyond the structured annotations.

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 long but well-organized into purpose, behavioral notes, parameter semantics, returns, and tool selection. It is front-loaded with the core purpose, and every section contributes needed information for correct invocation.

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?

Given the tool has 4 parameters, 5 enum states, no schema descriptions, and an output schema, the description covers all required cases: state meanings, argument dependencies, timeout behavior, error handling, and return values. Nothing needed for correct use 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 carries full responsibility for parameters. It thoroughly explains each state value, the selector requirement rule, text-search behavior, timeout semantics including the >= 0 constraint, and the equivalence of present/visible and absent/not_visible when text is supplied.

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: 'Wait for a page condition or for a specified duration.' It then explicitly differentiates itself from check_if_condition and assert_condition, so an agent can select it correctly without inspecting siblings.

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?

There is an explicit 'Tool selection' section mapping immediate inspection to check_if_condition, synchronization to wait_for_condition, and verification to assert_condition. It also clarifies when selector/text are required or ignored, leaving no ambiguity about when to use the tool.

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