Skip to main content
Glama
Sign In
chrome

chrome

by wellrccity
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Visual snapshot (screenshot or surface summary)

visual

Captures the page's current visual state—modals, overlays, dropdowns, iframes—as a compact JPEG or text-only summary to orient before DOM snapshots.

Instructions

Capture what is visually on the surface of the page right now — including modals, overlays, dropdowns, iframes and floating UI. Returns a compact JPEG screenshot (or a text summary of open modals/overlays if textOnly=true for non-vision models). Use this FIRST before snapshot/DOM when you need to understand the current visual state. Much cheaper than a full accessibility tree for orientation.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "visual"
  }
}

Input Schema

NameRequiredDescriptionDefault
tabIdNo
qualityNoJPEG quality 30-95. Default 72.
fullPageNoCapture the full scrollable page instead of just the viewport.
maxWidthNoMax width in px. Default 1280.
textOnlyNoReturn a text summary of visible modals, overlays and iframes instead of an image. Ideal for non-vision models to avoid image token costs.
maxHeightNoMax height in px. Default 900.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full disclosure burden. It does useful work by stating the return format (compact JPEG or text summary), the transient 'right now' nature of the capture, and the cost profile. It does not state that the operation is read-only, how the target tab is chosen when tabId is omitted, or what happens on capture failure, which matters for a six-parameter tool with zero annotation coverage.

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?

Three tight sentences: capability and coverage first, return format second, usage routing last. Every clause earns its place and there is no redundant restatement of the name or title.

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 zero-required-parameter capture tool with no output schema and no annotations, the description covers what is returned, how to get a non-image variant, and when to prefer it over DOM inspection. Remaining gaps are the default tab selection and failure behavior, which are minor relative to the tool's simplicity.

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 83%, so the schema already documents quality, fullPage, maxWidth, maxHeight and textOnly. The description reinforces textOnly's intent (non-vision models, avoiding image token costs) but adds no syntax or default detail for tabId, which is the one undocumented parameter. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with a concrete verb and resource: capture the visual surface of the page, including modals, overlays, dropdowns, iframes and floating UI. It clearly distinguishes itself from snapshot and dom, but never mentions the sibling screenshot tool, so an agent cannot fully resolve which of the two image-producing tools to pick from purpose text alone.

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?

It gives a direct ordering rule ('Use this FIRST before snapshot/DOM') plus the condition that selects the text variant (textOnly=true for non-vision models). It also frames the cost tradeoff versus a full accessibility tree. The only gap is the absence of guidance versus the screenshot sibling and no when-not-to-use case.

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