Browser Session MCP

Overview Schema Source Related Servers Discussions Admin

evaluate

Destructive

Runs JavaScript in a browser tab and returns its value as JSON, letting agents read page globals or compute values in the live page. Use when snapshot or wait tools can't get the data.

Instructions

Run JavaScript in a tab and return its value as JSON in { result }. A bare expression returns its value; for several statements use return ...; promises are awaited. Values that aren't JSON come back reduced: undefined as null and DOM nodes as {}. It runs in the page's main world (can read page globals like window.dataLayer); on stealth sessions (see set_stealth) it runs in an isolated world instead, which sees the DOM but not page-defined globals. tabIndex runs it in another tab without switching to it. The code can change the page like any script, so prefer take_snapshot or wait_for when they suffice, and click or type for interaction. Fails with the JS exception's message if the code throws.

Input Schema

Name	Required	Description
`tabIndex`	No	Tab to run in, by its 0-based list_pages index. Default: the active tab.
`sessionId`	Yes	The id returned by open_browser_session. Errors if no open session has it.
`expression`	Yes	JavaScript to run. Promises are awaited; the value must be JSON-serializable.

Output Schema

Name	Required	Description	Default
`result`	Yes	The expression's value; null for undefined.

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": {
+    "result": {
+      "description": "The expression's value; null for undefined."
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "type": "object"
+}

Changed3 schema fields changedOct 23, 2026

addedInput schema / properties / expression / description

Added value: +"JavaScript to run. Promises are awaited; the value must be JSON-serializable."

addedInput schema / properties / sessionId / description

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

addedInput schema / properties / tabIndex / description

Added value: +"Tab to run in, by its 0-based list_pages index. Default: the active tab."

First observedv0.1.2Oct 23, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Despite annotations covering the safety profile, the description adds substantial context beyond them: main-world vs isolated-world execution on stealth sessions, value coercion rules (undefined→null, DOM nodes→{}), promise awaiting, error behavior on thrown exceptions, and the page-mutating nature consistent with destructiveHint=true. No contradiction with annotations.

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?

The description is dense but front-loaded, moving from core behavior to return semantics, execution-world caveats, alternatives, and failure mode without a wasted sentence.

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 3 well-documented parameters, an output schema, and rich annotations, the description still covers the critical agent-facing unknowns: execution world, stealth world isolation, tab targeting, coercion, and error signaling.

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 the baseline is 3, but the description adds genuine meaning: it explains that tabIndex runs the code in another tab 'without switching to it' and that the stealth world affects what globals the expression can see, both of which go beyond the schema wording.

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 opens with a specific verb and resource ('Run JavaScript in a tab') and names the exact return shape (JSON in { result }), which lets an agent distinguish it from siblings like take_snapshot, click, or wait_for immediately.

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 routes the agent away from itself when simpler tools suffice: 'prefer take_snapshot or wait_for when they suffice, and click or type for interaction.' That is an explicit when-not-to-use statement with named alternatives.

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