js-reverse-mcp

by zhangjia2024

Overview Schema Source Related Servers Discussions Admin

evaluate_script

Destructive

Evaluates one focused JavaScript function to inspect DOM/page state, storage, page globals, paused-frame expressions, or process a local file in browser; use outputFile for large or binary results.

Instructions

Evaluates one focused JavaScript function for DOM/page state, web storage, page-defined globals, a paused-frame expression, or browser-side processing of one local file. Use it when those runtime values are the goal and no narrower evidence tool applies. Do not use document.cookie or page evaluation to investigate HttpOnly/Secure cookies, Set-Cookie provenance, or captured HTTP evidence; use list_network_requests with cookieName/reqid, and use search_in_sources/get_script_source for source discovery. While running, evaluation uses the selected frame's isolated world by default or its page main world with mainWorld=true; while paused, it always uses the chosen call frame and ignores mainWorld. Call get_paused_info before paused evaluation, then step or resume when finished. Arbitrary code can change page/external state and requires confirm=true; inline results are bounded, so use outputFile for exact large or binary results.

Input Schema

Name	Required	Description
`confirm`	No	Must be true to authorize this exact arbitrary-code evaluation, which may mutate page state, send requests, or cause external side effects. Prefer a read-only expression when inspection is sufficient.
`function`	Yes	JavaScript function declaration invoked by the tool, for example `() => document.title` or `async () => await Promise.resolve(location.href)`. Return JSON-serializable data; ArrayBuffer/typed arrays require outputFile for exact bytes. With localFilePath, accept `async ({localFile}) => ...` and read localFile.text for UTF-8 or localFile.base64 for exact bytes. Keep the function focused; use mainWorld=true only when page-defined globals are required.
`mainWorld`	No	Running-page mode only: false uses the selected frame's isolated context; true uses that frame's page main world to access application-defined globals. When execution is paused, evaluation always targets frameIndex and this option is ignored.
`frameIndex`	No	Paused mode only: zero-based call frame from get_paused_info (default: top frame). The index and its callFrameId expire after any step or resume.
`outputFile`	No	Save the exact result locally instead of returning bounded inline content. JSON-serializable values are written as JSON text and ArrayBuffer/typed arrays as raw bytes; the returned filename is resolved and subject to --allowedRoots.
`localFilePath`	No	Absolute path to one host file passed as localFile; the browser never reads the path directly. Running-page input is limited to 10 MiB, while paused call-frame input remains limited to 512 KiB. Relative paths, file:// URLs, globs, ~, and directories are rejected, access is subject to --allowedRoots, and file contents may expose sensitive host data.
`confirmOverwrite`	No	Set true only to authorize replacing an existing outputFile. A new file does not require overwrite confirmation.

Output Schema

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No
`tool`	Yes	Stable MCP tool name.
`error`	No
`summary`	Yes	Concise human-readable outcome.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.0.5Oct 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations, the description explains isolated-world versus mainWorld execution, that paused evaluation always targets the chosen call frame and ignores mainWorld, that frame/callFrameId expire after stepping or resuming, and that arbitrary code can mutate page or external state and requires confirm=true. It also discloses bounded inline results and the outputFile workaround for large or binary data.

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?

The description is dense and front-loads the core purpose, then adds usage, exclusions, runtime-mode caveats, and safety requirements. It is longer than typical, but nearly every sentence carries actionable information for a high-risk evaluation tool.

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 the dangerous, open-world nature of arbitrary code evaluation, the description covers intended use, prohibited use, execution contexts, paused-mode workflow, confirmation requirements, and large-result handling. With a rich input schema and output schema present, this is sufficiently complete for correct invocation.

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 in detail. The description adds some useful cross-parameter context, such as paused mode ignoring mainWorld and using the selected call frame, but it largely repeats what the schema already provides.

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 uses a specific verb and resource: evaluating one focused JavaScript function for runtime values such as DOM state, web storage, globals, paused-frame expressions, or local-file processing. It clearly distinguishes the tool from sibling evidence tools by naming network-request and source-discovery alternatives.

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 gives explicit use conditions ('when those runtime values are the goal and no narrower evidence tool applies') and explicit exclusions for cookies and source discovery. It routes the agent to list_network_requests, search_in_sources, and get_script_source, and states when to call get_paused_info before paused evaluation.

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