Skip to main content
Glama
frsorrentino

Chrome Bridge

by frsorrentino
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

emulate_media

Idempotent

Test how pages respond to dark mode, reduced motion, print styles, device viewports, touch, CPU/network limits, and user agents without changing real browser settings.

Instructions

Make the page believe it runs elsewhere, until reset or reload: prefers-color-scheme, prefers-reduced-motion, print mode, navigator.userAgent/platform. user_agent changes only what page JS reads — the request header is network_rules modify_header. via "page" (default for these) only patches matchMedia and, for reduce, zeroes every animation: the site's own @media rules do not apply. via "debugger" emulates like DevTools, so the site's @media (prefers-reduced-motion) rules really apply — use it to check reduced motion with animations — and adds contrast, CPU throttling, network profiles, device viewport with DPR, touch (these imply via debugger). via debugger keeps Chrome's "started debugging this browser" bar until reset: true; in launch mode nobody sees it. Pair with viewport_resize to emulate a device in page mode.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viaNopage: script shim, no browser bar; debugger: real emulation (default when a debugger-only option is set)
resetNoRemove all emulations and detach the debugger
touchNoEmulate a touch screen (debugger)
deviceNoDevice metrics override (debugger)
tab_idNoTarget tab; omitted = last tab navigated in this session, else the active one
networkNoDevTools network profile; none turns it off (debugger)
contrastNoValue reported to prefers-contrast queries (debugger)
printModeNoMake print media queries match, without opening a print dialog
user_agentNoOverrides navigator.userAgent and appVersion in the page (not the HTTP header)
colorSchemeNoValue reported to prefers-color-scheme queries
cpu_throttleNoCPU slowdown factor, e.g. 4 for a mid-range phone; 1 turns it off (debugger)
reducedMotionNoValue reported to prefers-reduced-motion queries

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.28.0
    • addedInput schema / properties / contrast
      Added value: +{
+  "description": "Value reported to prefers-contrast queries (debugger)",
+  "enum": [
+    "more",
+    "less",
+    "no-preference"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / cpu_throttle
      Added value: +{
+  "description": "CPU slowdown factor, e.g. 4 for a mid-range phone; 1 turns it off (debugger)",
+  "type": "number"
+}
    • addedInput schema / properties / device
      Added value: +{
+  "description": "Device metrics override (debugger)",
+  "properties": {
+    "dpr": {
+      "default": 1,
+      "description": "Device pixel ratio",
+      "type": "number"
+    },
+    "height": {
+      "description": "Viewport height in CSS px",
+      "type": "number"
+    },
+    "mobile": {
+      "default": false,
+      "description": "Mobile viewport: meta viewport and overlay scrollbars apply",
+      "type": "boolean"
+    },
+    "width": {
+      "description": "Viewport width in CSS px",
+      "type": "number"
+    }
+  },
+  "required": [
+    "width",
+    "height"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / network
      Added value: +{
+  "description": "DevTools network profile; none turns it off (debugger)",
+  "enum": [
+    "offline",
+    "3g",
+    "slow-4g",
+    "fast-4g",
+    "none"
+  ],
+  "type": "string"
+}
    • changedInput schema / properties / reset / description
      Previous value: -"Remove all emulations"New value: +"Remove all emulations and detach the debugger"
    • addedInput schema / properties / touch
      Added value: +{
+  "description": "Emulate a touch screen (debugger)",
+  "type": "boolean"
+}
    • addedInput schema / properties / via
      Added value: +{
+  "description": "page: script shim, no browser bar; debugger: real emulation (default when a debugger-only option is set)",
+  "enum": [
+    "page",
+    "debugger"
+  ],
+  "type": "string"
+}
  2. Changed4 schema fields changedv1.10.0
    • addedInput schema / properties / colorScheme / description
      Added value: +"Value reported to prefers-color-scheme queries"
    • addedInput schema / properties / printMode / description
      Added value: +"Make print media queries match, without opening a print dialog"
    • addedInput schema / properties / reducedMotion / description
      Added value: +"Value reported to prefers-reduced-motion queries"
    • addedInput schema / properties / tab_id / description
      Added value: +"Target tab; omitted = last tab navigated in this session, else the active one"
  3. Changed1 schema field changedv1.9.0
    • addedInput schema / properties / user_agent
      Added value: +{
+  "description": "Overrides navigator.userAgent and appVersion in the page (not the HTTP header)",
+  "type": "string"
+}
  4. First observedv1.8.0

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations (idempotent, non-destructive): the emulation persists only 'until reset or reload', page mode patches matchMedia but leaves @media rules unapplied and zeroes every animation for 'reduce', and debugger mode leaves Chrome's 'started debugging this browser' bar visible until reset:true (avoided in launch mode). These side effects and limitations are exactly what an agent needs and cannot get from the schema or annotations.

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?

Front-loaded with the core purpose, then organized by mode, and it is informationally dense with no filler sentences. It is long for a single paragraph and repeats 'via debugger' several times, which slightly hurts scanning, but each clause carries distinct technical weight.

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 complex 12-parameter tool with no output schema, the description covers mode selection, persistence, and caveats thoroughly. It does not state what a successful call returns or confirms, but for an emulation toggle where the observable effect is the page state, this is a minor omission.

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

Parameters4/5

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

Schema coverage is 100%, so title/description semantics are already documented (baseline 3). The description goes further by explaining the interaction rules the schema cannot express: which options imply via=debugger, that user_agent does not affect the HTTP header, and that page mode's shim only covers matchMedia. This materially clarifies parameter behavior beyond the field-level 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?

States a specific verb and resource ('Make the page believe it runs elsewhere') and enumerates the exact media features it controls (prefers-color-scheme, reduced motion, print mode, userAgent/platform). It explicitly separates itself from network_rules ('user_agent changes only what page JS reads — the request header is network_rules modify_header') and names viewport_resize as a companion, so an agent can place it among siblings without opening any 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?

Gives explicit when-to-use guidance for the two modes: 'via page (default for these)' for matchMedia-only patching, and 'via debugger' when the site's own @media rules must really apply, adding contrast, CPU throttling, network profiles, viewport DPR and touch (which imply via debugger). It also states when reset is needed ('until reset: true') and routes header-only overrides to a sibling.

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