Airbrowser

Overview Schema Source Related Servers Discussions Admin

start_browser

Start a persistent browser session before automating web tasks, maintaining cookies, tabs, and state across subsequent interactions via CDP.

Instructions

Launch a persistent SeleniumBase Pure CDP Mode browser session.

Call this before using browser interaction tools such as open_url, get_content, click_element, type_text, or find_elements. The same browser session remains active across subsequent MCP tool calls until close_browser is called or the server process exits.

Pure CDP Mode controls the browser through the Chrome DevTools Protocol (CDP), not WebDriver.

Args: url: Optional URL to navigate to during browser startup. When provided, the tool waits for the browser launch/navigation operation to complete before returning. If omitted, the browser starts without navigating to a specified URL.

headless: Controls whether the browser runs without a visible window.
    True forces headless mode; False forces headed mode. If None, this
    tool defaults to headless on Linux and headed on Windows/macOS.

use_chromium: Use Chromium instead of Google Chrome. This is useful
    when Google Chrome is not installed. SeleniumBase can manage the
    Chromium browser when this option is enabled.

browser_executable_path: Optional path to the browser executable.
    Use this when the desired browser is installed at a non-standard
    location. Mutually exclusive with use_chromium.

incognito: Launch Chrome/Chromium in incognito mode.

guest: Launch Chrome/Chromium in guest mode.
    Do not combine this with incognito=True.

ad_block: Enable SeleniumBase's basic ad-blocking functionality.

proxy: Optional proxy server.
    Examples include "SERVER:PORT" or "USER:PASS@SERVER:PORT".

Returns: A confirmation message when the browser starts successfully, or a descriptive error if the browser startup fails.

Startup behavior: If the initial launch fails, the tool automatically retries once.

Lifecycle: Call start_browser once at the beginning of a browser automation workflow. Reusing the existing session preserves cookies, tabs, navigation history, localStorage/sessionStorage, and other browser state between tool calls. Call close_browser when finished. If a browser session is already running, this tool does not launch another browser and instead returns a message indicating that the existing session is active.

Environment requirements: The MCP runtime must have a compatible Chrome or Chromium browser available. If the browser executable cannot be discovered, use use_chromium=True or provide browser_executable_path explicitly.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No
`guest`	No
`proxy`	No
`ad_block`	No
`headless`	No
`incognito`	No
`use_chromium`	No
`browser_executable_path`	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 burden and does so richly: automatic single retry on launch failure, session persistence across calls (cookies, tabs, history, localStorage/sessionStorage), idempotent behavior when a session exists, OS-dependent headless default, and mutual-exclusivity constraints (guest vs incognito, browser_executable_path vs use_chromium). Environment requirements and fallback paths are also disclosed.

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?

Well front-loaded — purpose and the call-ordering rule come first, then Args, Returns, Lifecycle, Environment. However, the Args block is verbose for a no-required-parameter tool, and the 'Returns' paragraph partially restates what the output schema already provides, adding length without new information.

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 an 8-parameter, zero-required, no-annotation session-launch tool, nothing an agent needs is missing: sequencing, idempotency, retry behavior, mutual exclusions, environment prerequisites, and cleanup via close_browser are all covered, and return values are backed by an output schema.

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 for all 8 parameters, and it does: it explains the null-vs-bool semantics of headless and its Linux/Windows/macOS default, gives proxy format examples ('SERVER:PORT', 'USER:PASS@SERVER:PORT'), states url triggers a wait for navigation, and documents two mutual-exclusivity constraints that the schema cannot express. This is meaning well beyond the bare parameter names.

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?

Opens with a specific verb+resource: 'Launch a persistent SeleniumBase Pure CDP Mode browser session,' and immediately distinguishes itself from siblings by naming the interaction tools it must precede (open_url, get_content, click_element, type_text, find_elements) and the sibling that ends it (close_browser). 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?

Explicitly states when to call ('before using browser interaction tools'), the lifecycle boundary ('once at the beginning of a workflow'), the termination counterpart (close_browser), and the when-not case ('If a browser session is already running, this tool does not launch another browser'). Alternatives and exclusions are spelled out rather than implied.

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