Skip to main content
Glama
wenym8

figmingo-mcp

by wenym8

compare_html_to_image

Renders HTML and pixel-diffs it against a reference image to detect visual differences, with per-band localization for identifying mismatches in specific design elements.

Instructions

One-shot visual comparison: renders an HTML page/element with Playwright (chromium) and pixel-diffs it against a reference image (e.g. a Figma export). passed = diffRatio <= maxRatio (default 0.01 = 1%; raise maxRatio for rework/triage loops where you only need localization, not a strict gate). Returns diff ratio, anti-alias accounting (see methodology in the response), and per-band diff localization — equal-height bands or custom bandEdges so one band can map to one design element. Replaces the manual render_html_screenshot → write-a-diff-script two-step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoRemote URL to render.
htmlNoRaw HTML string to render.
bandsNoSplit the image vertically into N equal-height horizontal bands and report per-band diff ratios. 0 = off. Ignored when bandEdges is set.
fullPageNo
htmlPathNoPath to a local HTML file.
maxRatioNoPass line: passed = diffRatio <= maxRatio. Default 0.01 (1%). For rework rounds, raise it (e.g. 0.05) so the call still "passes" while you use bands/bandEdges to localize remaining diffs.
selectorNoCSS selector for a partial (element) screenshot.
settleMsNo
bandEdgesNoCustom band boundaries, e.g. [0,120,280,974] → 3 bands [0,120) [120,280) [280,974). Lets one band map to one design element. Values are clamped to the image height, sorted, deduped. Mutually exclusive with bands — when both are given, bandEdges wins.
hideFixedNoHide position:fixed/sticky elements before shooting.
imagePathYesPath to the reference image (PNG) to compare against.
thresholdNopixelmatch color-delta threshold (0-1). Smaller = stricter per-pixel color comparison.
initScriptNoJS run before page scripts (addInitScript) — passed through to the renderer, e.g. seed localStorage/state for multi-state replicas.
outDiffPathNoWhere to save the diff PNG (red = mismatch). Temp file if omitted.
outRenderPathNoAlso save the rendered screenshot to this path and return it as renderPath. Useful when you need the render PNG itself (e.g. measuring line widths) without a second render_html_screenshot call.
viewportWidthNo
waitForImagesNo
keepRenderPathNoDeprecated alias of outRenderPath. If both are set, outRenderPath wins.
viewportHeightNo
Behavior4/5

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

No annotations provided; the description discloses core behavior: returns diff ratio, anti-alias accounting, per-band diff localization, pass/fail logic, and mutual exclusivity of bands/bandEdges. It could add more on side effects, but covers essential traits.

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 paragraph of ~120 words, front-loaded with purpose. It efficiently covers key points but could be structured into shorter sentences for better readability; still not verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (19 parameters, no output schema), the description explains workflow, pass/fail, and band localization. However, it lacks explicit output structure (only mentions diff ratio and anti-alias but says 'see methodology in the response'), which reduces completeness for an agent needing to parse results.

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 description coverage is 74%; the description adds meaning beyond the schema for key parameters like maxRatio (when to raise), bands/bandEdges (mutual exclusion, mapping to elements), and outRenderPath (avoiding second call). Not all parameters get extra context, but the added value is significant.

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 clearly states the verb ('One-shot visual comparison'), resource ('HTML page/element pixel-diffs against reference image'), and distinguishes it from siblings like render_html_screenshot (replaces manual two-step).

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 explains when to use (visual regression) and provides contextual guidance (raising maxRatio for rework loops). It doesn't explicitly list when not to use but implies it replaces a manual two-step, providing good context among siblings.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wenym8/figmingo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server