Skip to main content
Glama
gaforov

selenium-mcp

by gaforov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

session_create

Open an additional independent browser session with its own cookies and login state, then make it active. Use it to test multiple users at once or compare states side by side.

Instructions

Open an additional, independent browser session (its own window, cookies, and login state) and make it the active one; all other tools act on the active session. Use it to test several users at once, such as a buyer and a seller, or to compare two states side by side. Switch between sessions with session_select. Takes the same options as start_browser. Returns the new session and overall status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
browserNoWhich browser to launch: chrome (default), firefox, or edge. It must be installed on this machine.chrome
headlessNoRun without a visible window (default false).
sessionIdNoOptional readable id for the session, e.g. 'buyer' or 'admin' (1-128 chars). Defaults to a random UUID.
windowSizeNoInitial window size, e.g. { width: 1440, height: 900 }. Change it later with the window tool's resize action.
browserArgsNoExtra command-line flags for the browser, e.g. ['--incognito']. Default none.
scriptTimeoutMsNoMaximum time an asynchronous script may run, in milliseconds (default 30000).
pageLoadTimeoutMsNoMaximum time a page load may take before navigate fails, in milliseconds (default 30000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.3.0
    • addedInput schema / properties / browser / description
      Added value: +"Which browser to launch: chrome (default), firefox, or edge. It must be installed on this machine."
    • addedInput schema / properties / browserArgs / description
      Added value: +"Extra command-line flags for the browser, e.g. ['--incognito']. Default none."
    • addedInput schema / properties / headless / description
      Added value: +"Run without a visible window (default false)."
    • addedInput schema / properties / pageLoadTimeoutMs / description
      Added value: +"Maximum time a page load may take before navigate fails, in milliseconds (default 30000)."
    • addedInput schema / properties / scriptTimeoutMs / description
      Added value: +"Maximum time an asynchronous script may run, in milliseconds (default 30000)."
    • addedInput schema / properties / sessionId / description
      Added value: +"Optional readable id for the session, e.g. 'buyer' or 'admin' (1-128 chars). Defaults to a random UUID."
    • addedInput schema / properties / windowSize / description
      Added value: +"Initial window size, e.g. { width: 1440, height: 900 }. Change it later with the window tool's resize action."
    • addedInput schema / properties / windowSize / properties / height / description
      Added value: +"Window height in pixels (240-4320)."
    • addedInput schema / properties / windowSize / properties / width / description
      Added value: +"Window width in pixels (320-7680)."
  2. Addedv0.2.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the burden and discloses the critical side effect: the new session becomes active and 'all other tools act on the active session'. It also states the return shape. It omits failure behavior, resource cost, and whether this spawns a new process vs. tab.

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?

Front-loads the core action and its key trait, then usage scenarios, then the sibling routing, then the option/return note. Four tight sentences with no filler.

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 session-creating tool with no output schema, the description covers purpose, active-session semantics, sibling routing, and return shape ('the new session and overall status'), while the schema fully documents parameters. Nothing essential to correct invocation 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 100%, so the schema already documents all seven parameters (browser enum, headless, sessionId, windowSize, browserArgs, timeouts). The description only adds 'takes the same options as start_browser', which is useful context but not parameter detail. Baseline 3 applies.

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 verb and resource (open a browser session) plus the distinguishing traits: 'additional, independent' with its own window, cookies, and login state, and that it becomes the active one. This clearly separates it from start_browser (first session) and session_select (switching).

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

Usage Guidelines4/5

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

Gives concrete usage scenarios (test several users like buyer/seller, compare two states) and names the switching alternative (session_select). It does not explicitly contrast against start_browser as the 'when not to use', leaving that inference to the word 'additional'.

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

Deploy Server

Other Tools