Skip to main content
Glama
Mingye-Lu

acrawl

by Mingye-Lu
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

execute_js

Run JavaScript in the page to inspect or modify DOM, trigger hover-dependent states, and wait for async UI updates when CSS selectors and standard interactions lack the needed control.

Instructions

Execute arbitrary JavaScript in the page context and return the evaluation result. The script runs in the browser's main frame with full access to the DOM, window, and page APIs. Use as a last resort when CSS selectors and other tools cannot achieve the interaction — prefer click, fill_form, and select_option for standard interactions. Optionally accepts hover_selector to hover over an element before executing the script, enabling inspection of CSS :hover styles and hover-triggered DOM changes. When the script triggers reactive DOM changes (e.g., .click() on a toggle), the return value may reflect pre-mutation state because frameworks schedule updates asynchronously. Set settle_ms (e.g., 50) to wait for reactivity to flush before capturing the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scriptYesJavaScript code to execute in the page context, serialized to JSON on return. Accepts an expression ("document.title"), a statement list whose final expression is the result ("const t = document.title; t.length"), or a body that returns explicitly ("return document.title"). Top-level 'await' is supported ("await fetch('/api/data').then(r => r.json())").
settle_msNoMilliseconds to wait after script execution before capturing the return value (max 5000). Use when the script triggers DOM mutations that a reactive framework (Vue, React, etc.) processes asynchronously — a value of 50-100ms allows framework reactivity to flush before reading state. Default: 0 (no delay).
hover_selectorNoOptional CSS selector or @eN ref (from page_map) of an element to hover over BEFORE executing the script. When provided, the mouse is moved over the element (triggering :hover CSS pseudo-class), then the script is evaluated. This allows inspecting hover-dependent computed styles (e.g. getComputedStyle(el).color after hover) or verifying hover-triggered DOM changes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.2
    • changedInput schema / properties / script / description
      Previous value: -"JavaScript code to execute in the page context. The return value of the last expression is serialized as JSON and returned. For async operations, use 'await' (the script is wrapped in an async function). Example: \"document.title\" or \"await fetch('/api/data').then(r => r.json())\"."New value: +"JavaScript code to execute in the page context, serialized to JSON on return. Accepts an expression (\"document.title\"), a statement list whose final expression is the result (\"const t = document.title; t.length\"), or a body that returns explicitly (\"return document.title\"). Top-level 'await' is supported (\"await fetch('/api/data').then(r => r.json())\")."
  2. Changed2 schema fields changedv0.12.6
    • addedInput schema / properties / hover_selector
      Added value: +{
+  "description": "Optional CSS selector or @eN ref (from page_map) of an element to hover over BEFORE executing the script. When provided, the mouse is moved over the element (triggering :hover CSS pseudo-class), then the script is evaluated. This allows inspecting hover-dependent computed styles (e.g. getComputedStyle(el).color after hover) or verifying hover-triggered DOM changes.",
+  "type": "string"
+}
    • addedInput schema / properties / settle_ms
      Added value: +{
+  "description": "Milliseconds to wait after script execution before capturing the return value (max 5000). Use when the script triggers DOM mutations that a reactive framework (Vue, React, etc.) processes asynchronously — a value of 50-100ms allows framework reactivity to flush before reading state. Default: 0 (no delay).",
+  "type": "integer"
+}
  3. Changed1 schema field changedv0.10.0
    • addedInput schema / properties / script / description
      Added value: +"JavaScript code to execute in the page context. The return value of the last expression is serialized as JSON and returned. For async operations, use 'await' (the script is wrapped in an async function). Example: \"document.title\" or \"await fetch('/api/data').then(r => r.json())\"."
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations, the description carries full disclosure burden. It transparently reports that the script runs in the page's main frame with full DOM/window access and warns that return values may reflect pre-mutation state due to reactive frameworks, suggesting settle_ms as mitigation. It does not mention potential side effects like page navigation or security implications, a minor omission, but coverage is strong overall.

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 but well-organized: purpose and usage guidance are front-loaded, followed by parameter-specific details. Every sentence adds value, though the length is slightly longer than strictly necessary; it remains efficient and scannable.

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 an arbitrary-JS execution tool with no output schema, the description covers all critical aspects: script syntax, execution environment, async caveats, and optional parameters. An agent receives everything needed to call it correctly and avoid common pitfalls, making it complete for its complexity.

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

Parameters5/5

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

Despite 100% schema coverage, the description adds significant semantic depth: it explains the three valid script forms (expression, statement list, explicit return), supports top-level await, and details hover_selector's purpose (inspecting :hover styles) and settle_ms's role in handling async reactivity. This goes well beyond the schema's basic field descriptions.

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 clearly states the tool's verb ('Execute'), resource ('arbitrary JavaScript in the page context'), and explicitly differentiates it from siblings by calling out 'prefer click, fill_form, and select_option for standard interactions.' This makes the tool's unique role unambiguous.

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 provides explicit guidance on when to use: 'Use as a last resort when CSS selectors and other tools cannot achieve the interaction' and names concrete alternatives. It also explains when hover_selector and settle_ms are beneficial, giving context for parameter usage. No ambiguity remains about when this tool should be selected.

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