Browser Session MCP

Overview Schema Source Related Servers Discussions Admin

load_browser_state

DestructiveIdempotent

Load saved cookies into an MCP browser session so it starts logged in. Use after opening the session and before navigating; reload open pages to apply the saved login.

Instructions

Load cookies saved by save_browser_state into this session, usually right after open_browser_session and before navigate, so the session starts logged in. Pages already open need a reload or navigate to use them. Loaded cookies replace any with the same name, domain and path; others are kept. Expired logins won't work again; if the site still asks to log in, use request_human_takeover and save again. Fails if no state has that name; list_browser_states shows the names.

Input Schema

Name	Required	Description	Default
`name`	Yes	Name of the saved state: letters, digits, '.', '_' and '-' only.
`sessionId`	Yes	The id returned by open_browser_session. Errors if no open session has it.

Output Schema

Name	Required	Description	Default
`name`	Yes
`cookieCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Oct 24, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "properties": {
+    "cookieCount": {
+      "format": "uint",
+      "minimum": 0,
+      "type": "integer"
+    },
+    "name": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "name",
+    "cookieCount"
+  ],
+  "type": "object"
+}

Changed2 schema fields changedOct 23, 2026

addedInput schema / properties / name / description

Added value: +"Name of the saved state: letters, digits, '.', '_' and '-' only."

addedInput schema / properties / sessionId / description

Added value: +"The id returned by open_browser_session. Errors if no open session has it."

First observedv0.1.2Oct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: exact replacement semantics (same name/domain/path overwritten, others kept), the fact that expired logins won't work, and the failure condition when no state exists. This directly explains the destructiveHint=true annotation rather than contradicting it.

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?

Front-loaded with the core action, then sequencing, then edge cases. Dense but every sentence carries operational information; slightly long for a two-parameter tool but not padded.

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?

An output schema exists so return values need no explanation, and the description covers sequencing, failure modes, cookie-overwrite behavior, and remediation. Nothing an agent needs to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already documented; the description still adds value by stating the failure condition for an unknown 'name' and pointing to list_browser_states for valid names, plus confirming sessionId must come from an open session.

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 ('Load cookies saved by save_browser_state into this session') and anchors itself in the workflow right after open_browser_session and before navigate, which distinguishes it from siblings like navigate or request_human_takeover.

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?

Gives explicit sequencing advice, notes that already-open pages need a reload/navigate, names the fallback (request_human_takeover) when cookies fail, and points to list_browser_states for discovery. Both when-to-use and when-not/alternative paths are covered.

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