Airbrowser

Overview Schema Source Related Servers Discussions Admin

assert_condition

Verify an expected browser condition, such as element visibility or URL match, and raise an error if the assertion fails or times out. Use for read-only checks that enforce page state without modifying content.

Instructions

Verify a browser condition and report failure as an error.

Use this tool when an expected page state must be explicitly verified. It is a read-only verification operation: it does not click, type, navigate, scroll, or otherwise intentionally modify the page.

Element and text assertions may block while SeleniumBase waits for the condition, up to timeout seconds. Title and URL assertions are checked immediately and ignore timeout. A failed assertion or timeout is handled by handle_sb_errors and returned as a descriptive tool error; it is not reported as a successful result.

Unlike check_if_condition, this tool does not merely return whether a condition is true: a failed expectation is an error. Unlike wait_for_condition, its purpose is to verify an expectation, not merely synchronize with a changing page.

Args: check: - "element_present": Verify that the selector identifies a present element. - "element_visible": Verify that the selector identifies a visible element. - "text_visible": Verify that expected text is visible within selector, or within the whole HTML document if selector is omitted. - "title": Verify the exact current page title immediately. - "url": Verify the exact current URL immediately. - "url_contains": Verify that the current URL contains expected immediately.

selector: CSS or SeleniumBase selector for element and text checks.
    Required for element checks; optional for text_visible.

expected: Expected text, title, or URL value. Required for
    text_visible, title, url, and url_contains.

exact: For text_visible only, require an exact text match instead
    of a substring match.

timeout: Maximum seconds to wait for element/text assertions.
    Must be >= 0. Ignored for title and URL assertions.

Returns: A confirmation message when the assertion passes. If the assertion fails or times out, the error handler returns the resulting error instead of a success message.

Tool selection: - Inspect a condition without failing -> check_if_condition. - Wait for a condition to become true -> wait_for_condition. - Verify that an expected condition is true -> assert_condition.

Input Schema

TableJSON Schema

Name	Required	Default
`check`	No	element_visible
`exact`	No
`timeout`	No
`expected`	No
`selector`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.15.0Sep 15, 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 behavioral burden and does so thoroughly: it declares read-only verification, lists what it does not do (click, type, navigate, scroll, modify), explains blocking behavior for element/text checks vs immediate title/url checks, and states that failures become descriptive tool errors via handle_sb_errors.

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?

The description is well front-loaded and structured into purpose, behavior, args, returns, and tool selection. It is slightly redundant because the sibling comparisons appear both in prose ('Unlike check_if_condition...') and again in the tool-selection bullets, but the length is largely justified by the tool's complexity and zero schema coverage.

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 no annotations, zero schema description coverage, and an output schema, the description provides everything an agent needs: purpose, usage alternatives, parameter semantics, blocking behavior, and failure handling. Return value details are present as helpful context even though the output schema already defines them.

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 check value, explains selector requirements for element vs text checks, expected requirements per check type, exact matching only for text_visible, and timeout behavior including the >=0 constraint and that it is ignored for title/url assertions.

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 states a specific verb and resource: verify a browser condition and report failure as an error. It clearly distinguishes the tool from check_if_condition and wait_for_condition, so an agent can identify its role without opening schemas.

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?

It explicitly says when to use this tool ('when an expected page state must be explicitly verified') and provides a dedicated tool-selection section contrasting it with check_if_condition and wait_for_condition. The conditions for choosing each alternative are fully specified.

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