chrome-dev-mcp

Overview Schema Source Related Servers Discussions Admin

evaluate_at_frame

Evaluate a JavaScript expression in a paused call frame to read local/closure variables and this, returning a readable preview; fails when execution is not paused.

Instructions

Evaluate a JavaScript expression in the scope of a paused call frame — it reads local variables, closure variables and the current this, which evaluate_js cannot. Only works while execution is paused: when it is not, this returns an error rather than silently falling back to global scope. Results come back as a preview — class name plus a first level of properties, marked … where Chrome truncated it — readable, not parseable as the value. Use get_debugger_state to find frame indices.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "expression": "<expression>"
    },
    "name": "evaluate_at_frame"
  }
}

Input Schema

Name	Required	Description	Default
`expression`	Yes	JS source evaluated as-is. A function is not called — wrap it: `(() => { ... })()`
`frameIndex`	No	Call frame index (0 = top frame); use get_debugger_state to find available frames

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.0.0Nov 2, 2026

changedInput schema / properties / expression / description

Previous value: -"JS expression to evaluate"New value: +"JS source evaluated as-is. A function is not called — wrap it: `(() => { ... })()`"

First observedv1.1.0Jun 24, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations carry only a title, so the description bears the full disclosure burden and does it well: the paused-state requirement, the error-instead-of-fallback behavior, and the shape of the return value (class name plus first-level properties, `…` where Chrome truncated, human-readable rather than parseable). That last point is critical since no output schema exists.

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?

Front-loaded with the core capability, then scope differentiation, then the hard precondition, then the return-format caveat. Every sentence carries information an agent needs; nothing is restated from the schema or title.

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 no output schema, the description must explain returns and does so (preview-shaped, truncated, not machine-parseable). Preconditions, error behavior, and frame discovery are all covered, so an agent has everything needed to call this correctly.

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 both parameters (expression, frameIndex) are already fully documented in the schema, including the wrap-a-function-in-an-IIFE note and the 0 = top frame convention. The description adds only the get_debugger_state pointer for frame indices, which the schema also contains. Baseline 3 is appropriate.

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?

States a specific verb and resource ('Evaluate a JavaScript expression in the scope of a paused call frame') and immediately delimits scope against the sibling evaluate_js by naming what it can read that evaluate_js cannot (locals, closures, `this`). An agent can distinguish the two tools without opening either schema.

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?

Explicit precondition ('Only works while execution is paused') with the failure mode spelled out (error, no silent fallback to global scope), plus a routing instruction to get_debugger_state for frame indices and an explicit contrast with evaluate_js. Both when-to-use and when-not-to-use are covered.

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