web-debug-mcp

Overview Schema Source Related Servers Discussions Admin

Evaluate JavaScript expression

web_debug_evaluate

Destructive

Evaluate JavaScript expressions in the active browser page to inspect runtime state and identify issues. Side effects are blocked by default and run only when explicitly enabled.

Instructions

Evaluate an expression in the local page runtime. Side effects are rejected unless explicitly enabled.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`sessionId`	Yes
`expression`	Yes
`allowSideEffects`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`ok`	Yes
`data`	No
`error`	No
`warnings`	Yes
`artifacts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.10.0Sep 8, 2026

addedOutput schema / definitions / JsonValue

Added value: +{
+  "allOf": [
+    {
+      "$ref": "#/definitions/__schema0"
+    }
+  ]
+}

changedOutput schema / definitions / __schema0 / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "type": "null"
-  },
-  {
-    "items": {
-      "$ref": "#/definitions/__schema0"
-    },
-    "type": "array"
-  },
-  {
-    "additionalProperties": {
-      "$ref": "#/definitions/__schema0"
-    },
-    "propertyNames": {
-      "type": "string"
-    },
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "items": {
+      "allOf": [
+        {
+          "$ref": "#/definitions/__schema0"
+        }
+      ]
+    },
+    "type": "array"
+  },
+  {
+    "additionalProperties": {
+      "allOf": [
+        {
+          "$ref": "#/definitions/__schema0"
+        }
+      ]
+    },
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  }
+]

changedOutput schema / properties / data / properties / value / $ref

Previous value: -"#/definitions/__schema0"New value: +"#/definitions/JsonValue"

Changed5 schema fields changedv0.7.0Sep 1, 2026

addedOutput schema / properties / data / additionalProperties
```
Added value: +false
```

removedOutput schema / properties / data / allOf

Removed value: -[
-  {
-    "$ref": "#/definitions/__schema0"
-  }
-]

addedOutput schema / properties / data / properties

Added value: +{
+  "description": {
+    "anyOf": [
+      {
+        "maxLength": 2000,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "type": {
+    "anyOf": [
+      {
+        "maxLength": 100,
+        "type": "string"
+      },
+      {
+        "type": "null"
+      }
+    ]
+  },
+  "value": {
+    "$ref": "#/definitions/__schema0"
+  }
+}

addedOutput schema / properties / data / required

Added value: +[
+  "value",
+  "type",
+  "description"
+]

addedOutput schema / properties / data / type
```
Added value: +"object"
```

First observedv0.5.0-next.0Aug 30, 2026

TDQS

A3.6/5.0

Behavior4/5

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

The description adds a meaningful behavioral detail not fully carried by annotations: side effects are rejected unless allowSideEffects is explicitly enabled. This aligns with destructiveHint=true and readOnlyHint=false and helps the agent understand the default safety boundary.

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?

Two short sentences with no filler; the core action is front-loaded and the safety caveat is added in a second sentence. Every word earns its place.

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

Completeness4/5

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

For a tool that evaluates expressions, the key calling context (local page runtime, side-effect policy) is present, and an output schema covers return values. It is slightly incomplete only in that it does not describe when to prefer this over sibling debug/inspection tools.

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?

With 0% schema description coverage, the description must compensate for parameter meaning. It clarifies the expression target and the allowSideEffects behavior, but it does not mention sessionId or explain the exact error/behavior when side effects are rejected, leaving partial coverage.

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?

The description clearly identifies a specific action (evaluate) and resource (expression in the local page runtime), so an agent can tell what it does. It does not explicitly contrast itself with siblings such as web_browser_action or web_next_inspect, so it stops short of full differentiation.

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?

No guidance is given on when to choose this tool over sibling tools, and no exclusions or alternatives are named. The side-effect note is a behavioral constraint rather than usage-selection guidance.

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

Deploy Server