Skip to main content
Glama
pluginslab

devtools-fleet-mcp

by pluginslab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

evaluate_script

Evaluate JavaScript inside the target page. The source can be provided inline or loaded from a local file. Returns the response as JSON, so returned values have to be JSON-serializable.

Instructions

Evaluate JavaScript inside the target page. The source can be provided inline or loaded from a local file. Returns the response as JSON, so returned values have to be JSON-serializable.

Input Schema

NameRequiredDescriptionDefault
argsNoAn optional list of arguments (element uids from the page content snapshot) to pass to the function.
formatNoHow to interpret the source. "function" treats it as a function declaration and supports args. "script" evaluates it as classic JavaScript and does not support args. Defaults to "function". ECMAScript modules are not supported.
pageIdYesTargets a specific page by ID.
filePathNoThe absolute or relative path to a file to save the script output to. If omitted, the output is returned inline.
functionNoJavaScript source to execute in the target page. Provide either this or sourcePath, but not both. The source is interpreted according to format. Example without arguments: `() => document.title` or `async () => await fetch("example.com")`. Example with arguments: `(el) => el.innerText`
sourcePathNoThe absolute or relative path to a JavaScript file on the MCP server's local filesystem. Provide either this or function, but not both.
dialogActionNoHandle dialogs while execution. "accept", "dismiss", or string for response of window.prompt. Defaults to accept.
waitForStableDomNoWhether to wait for the DOM to settle. Pass false if the script only reads data. Defaults to true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.1.1
    • changedInput schema / additionalProperties
      Previous value: -{}New value: +false
    • changedInput schema / properties / args / description
      Previous value: -"An optional list of arguments to pass to the function."New value: +"An optional list of arguments (element uids from the page content snapshot) to pass to the function."
    • addedInput schema / properties / format
      Added value: +{
+  "description": "How to interpret the source. \"function\" treats it as a function declaration and supports args. \"script\" evaluates it as classic JavaScript and does not support args. Defaults to \"function\". ECMAScript modules are not supported.",
+  "enum": [
+    "function",
+    "script"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / function / description
      Previous value: -"A JavaScript function declaration to be executed by the tool in the target page.\nExample without arguments: `() => document.title` or `async () => await fetch(\"example.com\")`.\nExample with arguments: `(el) => el.innerText`\n"New value: +"JavaScript source to execute in the target page. Provide either this or sourcePath, but not both. The source is interpreted according to format.\nExample without arguments: `() => document.title` or `async () => await fetch(\"example.com\")`.\nExample with arguments: `(el) => el.innerText`\n"
    • addedInput schema / properties / sourcePath
      Added value: +{
+  "description": "The absolute or relative path to a JavaScript file on the MCP server's local filesystem. Provide either this or function, but not both.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "pageId",
-  "function"
-]New value: +[
+  "pageId"
+]
  2. First observedv0.1.0

TDQS

B3.3/5.0
Behavior3/5

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

The description adds real behavioral context beyond the single readOnlyHint=false annotation: output is returned as JSON so return values must be JSON-serializable, and the file/inline duality is explained. However, it omits the critical implication of arbitrary code execution — that scripts can mutate page state, trigger navigation, or have side effects — which is exactly what the false readOnlyHint warns about.

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?

Three tight sentences: purpose first, source modes second, return-format constraint last. No filler, no repetition of the tool name, and the most consequential caveat (JSON-serializable returns) is stated plainly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 8 optional-heavy parameters, a single weak annotation (readOnlyHint=false), and no output schema, the description should disclose that arbitrary JS can mutate or navigate the page and that failures/console errors surface elsewhere (list_console_messages). It covers the return shape but leaves the risk profile and failure behavior to inference.

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 coverage is 100% and the schema itself carefully documents format, args, function vs sourcePath, dialogAction, and waitForStableDom. The description only restates the inline-vs-file choice, adding nothing about the function/script distinction, dialog policy, or DOM-stability default. Baseline 3 is appropriate when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Evaluate JavaScript inside the target page', plus the two source modes (inline or local file). No sibling tool performs arbitrary in-page JS evaluation, so it is distinguishable by default, but the description never names an alternative or scope boundary explicitly.

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

Usage Guidelines2/5

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

There is no when-to-use vs when-not guidance, no mention of prerequisites (e.g., page must be selected/loaded), and no comparison to siblings like take_snapshot, get_console_message, or get_css_styles that cover narrower read needs. The only selection guidance ('inline or loaded from a local file') mirrors the schema's mutual-exclusion rule rather than adding usage context.

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