Skip to main content
Glama
Sign In
pironjulien

nexus-browser

by pironjulien
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_eval

Destructive

Execute JavaScript in the page's own context, like DevTools console, to inspect or modify page state and return the result.

Instructions

Runs a JavaScript expression in the PAGE WORLD (its variables and functions, like the DevTools console) and returns the result. The only tool that runs code there: the page can see and tamper with what happens in it. The other tools read and act from an isolated world the page cannot see.

FULL PAGE ACCESS, nothing is masked in the result: the script reads everything the page reads (non-HttpOnly cookies via document.cookie, localStorage, sessionStorage, IndexedDB, form fields, passwords included) and fetch goes out with the user's session. The masking of the other tools (cookies, headers, bodies, passwords) does not apply here: do not read or return any secret the task does not require.

NOT covered by the outward-action accord check (full page access by design): never use it to click, submit or send what browser_click, browser_press_key or browser_type_keys would refuse without the user's accord.

Input Schema

NameRequiredDescriptionDefault
scriptYes
tab_idYesYour tab's id (from browser_new_tab, or a tab adopted with browser_adopt_tab).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.31.6
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "browser_evalOutput",
-  "type": "object"
-}New value: +null
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations (destructiveHint=true, openWorldHint=true, non-idempotent) only flag risk in the abstract; the description supplies the actual behavioral facts: the page can see and tamper with execution, masking applied by other tools does not apply, fetch carries the user's session, and the outward-action accord check is not enforced here. That is exactly the context an agent needs to avoid leaking secrets or performing unguarded writes.

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 behavior and the sibling distinction, then layers risk warnings in descending priority. It is longer than typical and repeats the masking point ('nothing is masked in the result' / 'the masking of the other tools ... does not apply'), which costs a little density, but every paragraph carries substantive guidance.

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 two-parameter, no-output-schema tool, the description covers purpose, execution context, safety posture, session implications, and the guardrail exception. Return values are inherently arbitrary JavaScript results, so no output schema or format explanation is needed; nothing an agent must know before calling 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 50% — tab_id is documented in the schema, but script has no description there. The description compensates by establishing that script is a JavaScript expression evaluated in the page world whose value is returned, which is more than the bare 'Script' title conveys. It does not clarify expression-vs-statement form, async handling, or serialization of the returned value, so it stops short of full coverage.

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: 'Runs a JavaScript expression in the PAGE WORLD ... and returns the result,' and immediately distinguishes itself from every sibling by contrasting page-world execution with the isolated world the other tools use. An agent can identify this tool and its unique capability without opening the 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 frames this as the DevTools-console-equivalent and the 'only tool that runs code there,' then gives a concrete when-not: never use it to click, submit, or send what browser_click, browser_press_key or browser_type_keys would refuse without the user's accord. Alternatives are named by tool name, so routing is unambiguous.

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