Skip to main content
Glama
WhiteNightShadow

camoufox-reverse-mcp

by WhiteNightShadow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

evaluate_js

Execute JavaScript in a page context to inspect or manipulate web pages, returning results with configurable frame targeting and output formatting.

Instructions

Execute an arbitrary JavaScript expression in the page context and return the result.

v1.0.1 fix: correctly handles undefined/null/void/Symbol return values without triggering JSON.parse crashes.

Default auto mode preserves legacy cleaning and smart JSON parsing; it may strip BOM/whitespace and replace lone surrogates. value_raw is not a code-unit-preserving transport. json_ascii returns explicit JSON text before transport/cleaning, preserving JSON string code units. Evaluation is never replayed after a failure.

Args: expression: JavaScript expression. Must be a single expression, not top-level var/let/const/function declarations (Playwright limitation). Wrap in IIFE if needed: (() => { var x = 1; return x; })() await_promise: If True, awaits Promise results (default True). world: "isolated" preserves the existing Playwright execution context. "main" prefers Camoufox's native mw: channel so page globals created by site scripts are visible, with an explicit Firefox window.wrappedJSObject.eval fallback for older/attached servers. frame_url: Optional exact frame URL or shell-style wildcard. frame_name: Optional exact frame name or shell-style wildcard. frame_index: Optional zero-based index from get_page_info().frames. result_format: "auto" (legacy cleanup) or "json_ascii" (ASCII JSON text in value, not parsed/trimmed). json_ascii follows JSON.stringify: tag non-finite numbers/-0/undefined explicitly if their distinction matters; it is not a lossless arbitrary-object graph serializer.

Returns: dict with keys: value - cleaned value (parsed JSON if applicable) value_raw - raw string before cleaning (only when cleaning applied) type - "primitive" | "json" | "handle_fallback" | "error" world - selected execution world frame - selected frame's current snapshot metadata execution_backend - isolated, Camoufox native, or wrappedJSObject warnings - list of applied cleanups, if any hint - (error only) friendly fix suggestion or None

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
worldNoisolated
frame_urlNo
expressionYes
frame_nameNo
frame_indexNo
await_promiseNo
result_formatNoauto

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.0
    • addedInput schema / properties / result_format
      Added value: +{
+  "default": "auto",
+  "title": "Result Format",
+  "type": "string"
+}
  2. Changed4 schema fields changedv1.6.0
    • addedInput schema / properties / frame_index
      Added value: +{
+  "title": "Frame Index",
+  "type": "integer"
+}
    • addedInput schema / properties / frame_name
      Added value: +{
+  "title": "Frame Name",
+  "type": "string"
+}
    • addedInput schema / properties / frame_url
      Added value: +{
+  "title": "Frame Url",
+  "type": "string"
+}
    • addedInput schema / properties / world
      Added value: +{
+  "default": "isolated",
+  "title": "World",
+  "type": "string"
+}
  3. First observedv0.3.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses return format keys, differences between auto and json_ascii modes, execution world behavior (isolated vs main with fallback), failure behavior ('Evaluation is never replayed after a failure'), and specific handling of undefined/null/void/Symbol. This is exceptionally transparent.

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 front-loaded with the core purpose and version note, then organized into Args and Returns sections. It is longer than necessary—the v1.0.1 changelog line and some verbosity could be trimmed—but it is well-structured and every section earns its place given the tool's complexity. The length is justified by the need to explain subtle behaviors.

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?

With 7 parameters, no output schema, and no annotations, this description is remarkably complete. It documents all return keys, error hint behavior, execution backends, and frame selection. The agent receives everything needed to call the tool correctly without additional external knowledge. It also preemptively addresses common pitfalls (e.g., lone surrogates, non-finite numbers).

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?

Schema description coverage is 0%, so the description must compensate entirely. It explains every parameter: expression (including the IIFE caveat), await_promise (default True), world (with isolated vs main details and fallback), frame_url/name/index (with wildcard support), and result_format (auto vs json_ascii). Each parameter's purpose and nuances are covered, exceeding what a bare schema would provide.

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 verb 'Execute an arbitrary JavaScript expression in the page context and return the result.' It names the resource (page context) and the specific action. No sibling tool performs the same function (e.g., hook_function injects hooks, not evaluate expressions), so differentiation is inherent.

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

Usage Guidelines4/5

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

The description gives clear guidance on how to use the tool (e.g., single-expression requirement, IIFE wrapping, world selection, frame targeting) but does not explicitly contrast with alternative tools or state when not to use it. Since it is a general-purpose evaluation tool, the context is clear enough for an agent to infer its appropriate use.

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