Skip to main content
Glama
congzhou09

chrome-dev-mcp

by congzhou09
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

screenshot

Read-only

Capture the visible viewport or a specified region of a web page as a PNG. Use it to inspect pixel rendering, alignment, or visual state of a Chrome tab.

Instructions

Capture a PNG screenshot of the current viewport (the visible page area only — not the full scrollable page, not the browser chrome, not DevTools), or of one rectangle of it with region. Captured at the tab's native pixel size unless you cap it with maxEdge; a capture that was scaled or cut says so in a note beside the image, which for a region also gives the CSS rect the image covers and how many image pixels a CSS pixel became. A tab that is not painting is raised in its window first, which changes which tab is selected there.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regionNoCapture only this rectangle instead of the whole viewport. CSS pixels, measured from the top-left of the visible area — the same space `getBoundingClientRect()` reports in, so an element's box can be passed straight through. Usually the right way to answer a question about exact pixels: a small region at native size costs far less than the whole viewport. Pad it a few pixels when judging alignment — an exact box crop puts the element's own antialiased edge in its outer row, and an offset only reads against its surroundings. Cut down to whatever part of it is on screen; a region entirely off screen is an error.
maxEdgeNoLongest side of the returned image, counted in its own pixels rather than CSS pixels, so the same value gives the same image on a 1x and a 2x tab. Scales down `region` when one is given, the viewport otherwise. -1 (the default), or any value at or above the capture's native pixel size, returns native pixels — use that when the answer depends on exact pixels (1px offsets, blurred edges, subpixel text). Otherwise size it for whatever will read the image: cost scales with AREA, so halving this quarters it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.4.3
    • addedInput schema / properties / maxEdge
      Added value: +{
+  "default": -1,
+  "description": "Longest side of the returned image, counted in its own pixels rather than CSS pixels, so the same value gives the same image on a 1x and a 2x tab. Scales down `region` when one is given, the viewport otherwise. -1 (the default), or any value at or above the capture's native pixel size, returns native pixels — use that when the answer depends on exact pixels (1px offsets, blurred edges, subpixel text). Otherwise size it for whatever will read the image: cost scales with AREA, so halving this quarters it.",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
    • addedInput schema / properties / region
      Added value: +{
+  "description": "Capture only this rectangle instead of the whole viewport. CSS pixels, measured from the top-left of the visible area — the same space `getBoundingClientRect()` reports in, so an element's box can be passed straight through. Usually the right way to answer a question about exact pixels: a small region at native size costs far less than the whole viewport. Pad it a few pixels when judging alignment — an exact box crop puts the element's own antialiased edge in its outer row, and an offset only reads against its surroundings. Cut down to whatever part of it is on screen; a region entirely off screen is an error.",
+  "properties": {
+    "height": {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "width": {
+      "exclusiveMinimum": 0,
+      "type": "number"
+    },
+    "x": {
+      "type": "number"
+    },
+    "y": {
+      "type": "number"
+    }
+  },
+  "required": [
+    "x",
+    "y",
+    "width",
+    "height"
+  ],
+  "type": "object"
+}
  2. First observedv1.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description reveals important behaviors: captures only visible area, scaled/cut captures produce a note with CSS rect and pixel conversion, and non-painting tabs are raised to the front, changing tab selection. It also explains cost scaling with area. These details go well beyond what annotations provide, giving the agent a clear model of side effects.

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 a single dense paragraph that front-loads the core function, then layers region and maxEdge guidance, and ends with the tab-raising side effect. Every sentence contributes value; it is efficient though slightly long. The structure is logical and easy to follow.

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?

The description covers the capture scope, region behavior, maxEdge scaling, cost implications, side effects on tab selection, and even error conditions (off-screen region). With no output schema, it implicitly clarifies that a PNG is returned. Nothing an agent needs to invoke it correctly 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?

Schema coverage is 100% and both parameters have detailed descriptions in the schema. The tool description adds some usage guidance (e.g., 'Usually the right way to answer a question about exact pixels') but does not introduce new parameter semantics beyond the schema. This matches the baseline of 3 for fully documented parameters.

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 states a specific verb ('Capture'), a precise resource (the current viewport or a region of it), and explicitly excludes full-page, browser chrome, and DevTools. It clearly distinguishes this as the only visual capture tool among siblings, so an agent knows exactly what it does and what it does not.

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 strong context on when to use region vs the whole viewport, when to use native pixel size vs maxEdge, and even advises padding for alignment. However, it does not explicitly contrast with alternative tools (e.g., get_html or evaluate_js) for gathering visual information, though none of those are screenshots. The guidance is otherwise clear and actionable.

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