Skip to main content
Glama
andresolbach

nodriver-mcp-server

Reset emulation

reset_emulation
Idempotent

Clear all emulation overrides—network throttling, geolocation, user agent, viewport, and touch—to restore real browser defaults. Use after emulate to return to ordinary Chrome behavior.

Instructions

Clear every emulation override on the selected page.

Resets in one call: network throttling, CPU throttling, geolocation, user agent and client hints, color scheme, viewport, device pixel ratio, page scale and touch emulation — back to the real browser defaults.

Use after emulate or emulate_device to make the page behave like ordinary desktop Chrome again. Turning touch emulation off here also restores trusted CDP clicks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
browserNoWhich browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.default

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.5.0
    • addedInput schema / properties / browser
      Added value: +{
      +  "default": "default",
      +  "description": "Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.",
      +  "type": "string"
      +}
  2. First observedv1.7.2

TDQS

A4.7/5.0
Behavior5/5

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

The description details the full scope of the reset, listing network throttling, CPU throttling, geolocation, user agent, client hints, color scheme, viewport, device pixel ratio, page scale, and touch emulation. It also discloses the CDP click restoration behavior. These specifics go well beyond the annotations (idempotentHint, destructiveHint) and give the agent a precise model of the tool's effects.

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?

The description is tightly structured: a one-line purpose, a list of reset items, and a usage note. Every sentence contributes new information—no fluff or repetition. The most critical detail (what it resets) is front-loaded, and the usage guidance is placed where it naturally follows.

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 a tool that resets many emulation categories, the description enumerates them all, making the tool's effect fully transparent. It also provides usage context and a side effect. The presence of an output schema means return values don't need explanation, and the parameter is covered by the schema. Nothing essential is missing.

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?

The single parameter 'browser' is fully documented in the schema with its own description covering default behavior and parallel-agent usage. The tool description adds no extra semantic detail about the parameter, but since schema coverage is 100%, a baseline of 3 is appropriate. The description's omission is not a gap because the schema already handles it.

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 uses a specific verb ('Clear') and resource ('every emulation override'), then enumerates the exact overrides it resets. It distinguishes itself from siblings like emulate and emulate_device by explicitly stating it is the counterpart that reverts them. This leaves no ambiguity about what the tool does.

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 explicitly states when to use it: 'Use after emulate or emulate_device to make the page behave like ordinary desktop Chrome again.' It also adds a specific side effect ('Turning touch emulation off here also restores trusted CDP clicks'), which informs the agent of an additional reason to call it. No exclusions are needed since the tool's purpose is narrowly scoped.

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