web-ui-tester

Start browser session

browser_start

Launch a persistent browser session for testing web UIs; cookies and page state stay alive across calls so agents can inspect and interact with the same page over many turns.

Instructions

Opens a new browser session and returns its sessionId. The session (cookies, storage, page state) stays alive across tool calls until closed or idle-timed-out, so you can interact with the same page over many turns.

Input Schema

TableJSON Schema

Name	Required	Description
`tab`	No	With the browser's profile: take over the open tab whose URL contains this, instead of opening a new tab. Closing the session leaves that tab open.
`url`	No	Navigate here immediately after starting.
`model`	No	Default model for run_task in this session, as "provider:modelId" (e.g. "google:gemini-flash-lite-latest" or "anthropic:claude-haiku-4-5").
`cdpUrl`	No	Attach to an already-running Chrome over the DevTools protocol instead of launching one, e.g. "http://127.0.0.1:9222" (Chrome started with --remote-debugging-port=9222). Defaults to WUT_CDP_URL when that is set.
`baseUrl`	No	Base URL that relative paths in browser_navigate resolve against.
`devtools`	No	Make chrome-devtools-mcp's tools (devtools.* in browser_list_tools) available by giving the browser a private DevTools port. Defaults to true (WUT_DEVTOOLS); false launches into a browser without one.
`headless`	No	Run headless. Defaults to true. Ignored when attaching over CDP.
`userAgent`	No	User-Agent for this session. Defaults to AITester/1.0.
`viewportWidth`	No
`viewportHeight`	No
`useBrowserProfile`	No	With cdpUrl: drive the browser's own profile (its cookies, logins and tabs). Defaults to true; false uses a fresh isolated context inside that browser.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 30, 2026

addedInput schema / properties / cdpUrl

Added value: +{
+  "description": "Attach to an already-running Chrome over the DevTools protocol instead of launching one, e.g. \"http://127.0.0.1:9222\" (Chrome started with --remote-debugging-port=9222). Defaults to WUT_CDP_URL when that is set.",
+  "type": "string"
+}

addedInput schema / properties / devtools

Added value: +{
+  "description": "Make chrome-devtools-mcp's tools (devtools.* in browser_list_tools) available by giving the browser a private DevTools port. Defaults to true (WUT_DEVTOOLS); false launches into a browser without one.",
+  "type": "boolean"
+}

changedInput schema / properties / headless / description

Previous value: -"Run headless. Defaults to true."New value: +"Run headless. Defaults to true. Ignored when attaching over CDP."

addedInput schema / properties / tab

Added value: +{
+  "description": "With the browser's profile: take over the open tab whose URL contains this, instead of opening a new tab. Closing the session leaves that tab open.",
+  "type": "string"
+}

addedInput schema / properties / useBrowserProfile

Added value: +{
+  "description": "With cdpUrl: drive the browser's own profile (its cookies, logins and tabs). Defaults to true; false uses a fresh isolated context inside that browser.",
+  "type": "boolean"
+}

First observedv0.1.0Aug 24, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true but say nothing about lifecycle. The description adds genuinely useful behavioral context: the session persists cookies/storage/page state across calls and ends only on close or idle timeout, and it clarifies the return contract (sessionId). It does not disclose auth, permissions, or resource costs.

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?

Two tight sentences with the core purpose and return value front-loaded, followed by the persistence/idle-timeout nuance. No filler or repetition of the title; the only slight excess is the parenthetical state list, which still earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter, zero-required session-creation tool with no output schema, the description covers purpose, lifecycle, and the returned sessionId adequately, while the schema handles parameter semantics. It could more explicitly guide interaction with sibling tools, but nothing critical for calling it correctly is missing.

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 82%, above the 80% threshold, so the schema already documents nearly all 11 parameters with rich per-field context (cdpUrl, tab takeover, devtools, useBrowserProfile, etc.). The description adds no parameter-level detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Opens a new browser session') and adds the return value ('returns its sessionId'). It implicitly distinguishes itself from browser_close via the lifecycle note, but does not explicitly name siblings like browser_navigate or browser_list, so it stops short of full differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The lifecycle statement ('stays alive across tool calls... so you can interact with the same page over many turns') implies this is the entry point for subsequent browser work but never states explicitly when to call it versus alternatives such as attaching via cdpUrl, using an existing profile, or navigating with browser_navigate. Usage is inferable but not prescribed.

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

Start browser session

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools