Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@visual-regression-mcp Compare the current dashboard against its baseline for visual regressions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI 辅助的视觉回归测试 MCP Server。像素对比找出差异，AI 判断这个差异是真 bug 还是可接受的变化。
视觉回归测试不是新技术，但传统方案有个致命问题：误报太多。
字体渲染差异、动画时序、随机数据、时间戳——这些都会导致像素差异，但都不是 bug。团队引入视觉回归测试后，往往因为每次 CI 都红、但 90% 是误报，最后干脆关掉。
这个项目的思路是：像素对比只负责"找出哪里不一样"，判断"这是不是 bug"交给 AI。
工具返回的不只是差异百分比，而是差异图 + 当前截图 + 区域定位。AI 看到图之后可以判断：
差异集中在按钮区域，颜色从绿变红 → 可能是真 bug
差异散布全页、每处都是 1-2 像素 → 字体抗锯齿，可忽略
差异在时间戳区域 → 动态内容，应该 mask 掉
Related MCP server: UI Screenshot Comparison MCP
工具 | 说明 |
| 截图并保存为基线。支持全页/元素截图、自定义视口、遮盖动态区域 |
| 对当前页面截图并与基线做像素对比，返回统计数据 + 差异图 + 当前截图 |
| 列出所有已保存的基线及其截图参数 |
| 删除过期基线（页面有意改版后） |
这是项目的核心，不是简单调 pixelmatch 就完事：
冻结动画 — 注入 CSS 把所有 animation-duration 和 transition-duration 归零，同时隐藏光标。CSS 动画是误报的头号来源。
遮盖动态区域 — maskSelectors 参数可以把时间戳、广告位、随机内容用纯色盖住，让这些区域的像素稳定。
参数持久化 — 基线保存时把视口尺寸、选择器、等待时间一起存下来，对比时用完全相同的参数重截。参数不一致的对比是无意义的。
等待网络空闲 — waitUntil: "networkidle" 加可配置的额外等待，避免图片没加载完就截图。
区域定位 — 把画面切成 3×3 网格统计差异分布。"差异集中在顶部导航"和"差异散布全页"含义完全不同，前者可能是布局 bug，后者多半是渲染差异。
尺寸不匹配单独处理 — 页面高度变了说明内容增删，pixelmatch 无法对比，此时直接报告尺寸变化而不是崩溃。
git clone <repo-url>/visual-regression-mcp.git
cd visual-regression-mcp
npm install
npx playwright install chromium
npm run build在 Claude Code 的 MCP 配置中添加：
{
"mcpServers": {
"visual-regression": {
"command": "node",
"args": ["/path/to/visual-regression-mcp/build/index.js"],
"env": {
"VISUAL_BASELINE_DIR": "/path/to/your/baselines"
}
}
}
}VISUAL_BASELINE_DIR 可选，默认存在 ~/.visual-regression-mcp/baselines/。
配置后重启 Claude Code，直接用自然语言：
帮我给 http://localhost:3000/dashboard 建一个视觉基线，命名 dashboard
（改了代码之后）
对比一下 dashboard 有没有视觉回归
把时间戳区域 .timestamp 遮盖掉再建基线AI 会调用工具、看差异图、然后告诉你这个差异是不是问题。
{
"status": "differences_found",
"name": "dashboard",
"diffPixels": 5107,
"totalPixels": 480000,
"diffPercent": 1.064,
"diffRegions": [
{ "region": "middle-left", "diffPixels": 5107, "percentOfRegion": 9.58 }
],
"note": "Pixel diff found. Inspect the diff image below..."
}外加两张图：差异图（品红高亮变化像素）和当前截图，供 AI 视觉判断。
@modelcontextprotocol/sdk — MCP 协议
playwright — 无头浏览器截图
pixelmatch + pngjs — 像素级图像对比
TypeScript + ESM
MIT
Capture a screenshot of a URL and save it as the visual baseline under a given name. Run this once on a known-good version of the page. Later use compare_visual against the same name to detect regressions.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture, e.g. http://localhost:3000/login | |
| name | Yes | Baseline identifier, e.g. 'login-page'. Used as the filename. | |
| width | No | Viewport width in px (default 1280) | |
| height | No | Viewport height in px (default 720) | |
| waitMs | No | Extra wait after network idle, in ms (default 500) | |
| fullPage | No | Capture the entire scrollable page (default true) | |
| selector | No | CSS selector to capture only one element instead of the page | |
| maskSelectors | No | CSS selectors for dynamic regions to mask out (timestamps, ads, random content) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the core behavior: captures a screenshot and saves it as a baseline. It also adds valuable context about using a known-good version. Minor gaps remain (e.g., overwrite behavior, storage location), but the primary side effect is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and no redundant content. Every phrase earns its place: action, purpose, usage context, and relation to sibling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a capture tool with rich schema annotations and no output schema, the description covers the workflow comprehensively. It explains what the tool does, when to run it, and how to use the result. The sibling context and schema fill in remaining details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all eight parameters. The description adds minimal parameter-specific meaning beyond naming 'name' as the baseline identifier, which is also in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'capture' and resource 'screenshot of a URL', clearly states it saves as a visual baseline under a given name. This distinguishes it from siblings like compare_visual, list_baselines, and delete_baseline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Run this once on a known-good version of the page' and directs to use compare_visual later, which differentiates from alternatives. This is clear when-to-use and points to relevant sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the current state of a URL and compare it pixel-by-pixel against a saved baseline. Returns diff statistics AND the diff image, so you (the AI) can visually judge whether the changes are real regressions or acceptable variations (font rendering, dynamic content, intentional redesign). Pixel diff alone produces many false positives — your visual judgment is the point of this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to capture (defaults to the URL stored with the baseline) | |
| name | Yes | Baseline identifier to compare against | |
| threshold | No | Per-pixel color sensitivity 0-1; lower is stricter (default 0.1) | |
| includeDiffImage | No | Return the diff image for visual inspection (default true). Set false for a stats-only check. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool captures a URL, compares against a saved baseline, and returns diff statistics and a diff image. However, it does not explicitly address side effects (e.g., whether a new screenshot is stored), permissions, or failure behaviors, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with an action verb and resource. Each sentence adds value: the first defines functionality and return content, the second explains the rationale and emphasizes the AI's role. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity with four parameters and no output schema. The description compensates by clearly stating return values (diff stats and diff image) and the intended use case (visual judgment of regressions). It lacks edge-case details like missing baselines or error handling, but overall provides sufficient context for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all parameters, so the bar is at baseline 3. The description does mention the diff image and false positives, which loosely relates to includeDiffImage, but it does not add significant semantic meaning beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Capture the current state of a URL and compare it pixel-by-pixel against a saved baseline.' This distinguishes it from sibling tools like capture_baseline and list_baselines by focusing on comparison rather than creation or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's role in detecting regressions and acknowledges that pixel diff alone yields false positives, implying when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the context is clear enough for an AI agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a saved baseline by name. Use when a page has intentionally changed and the old baseline is obsolete.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Baseline identifier to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states that deletion happens, but does not mention whether the deletion is permanent, what happens if the baseline does not exist, or any side effects on associated comparisons. The word 'Delete' implies mutability, but the lack of detail about consequences is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the action front-loaded in the first sentence and a brief usage context in the second. Every word contributes to clarity without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and absence of annotations, the description conveys purpose and usage but omits important behavioral aspects like permanence or error handling. It is adequate for understanding when to call the tool but not fully complete for anticipating consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% description coverage for the only parameter 'name' as 'Baseline identifier to delete'. The description merely repeats 'by name' without adding format details, constraints, or examples, so it does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a saved baseline by name', specifying the verb, resource, and method of identification. This distinguishes it from sibling tools like capture_baseline, compare_visual, and list_baselines, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific condition: 'Use when a page has intentionally changed and the old baseline is obsolete.' This gives clear context for when deletion is appropriate, although it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all saved visual baselines with their URLs and capture settings.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates a read-only listing operation and reveals what the return will contain (URLs and capture settings), but it does not mention side effects, ordering, pagination, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant or vague phrasing. Every word contributes to the reader's understanding of what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description sufficiently conveys the tool's purpose and the content of the list. It could be slightly richer with contextual cues about when to use it relative to siblings, but it is complete enough for the simple operation it describes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the empty input schema is fully covered. There is nothing meaningful to add semantically, and per the rubric, a 0-parameter tool receives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all saved visual baselines and includes URLs and capture settings. This is a specific verb+resource combination that distinguishes it from sibling tools like capture_baseline, compare_visual, and delete_baseline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case of listing existing baselines is implied by the verb 'list', but the description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. There is no direct guidance beyond the clear purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0capture_baselinecompare_visualdelete_baselinelist_baselinesEach tool has a clearly distinct purpose: capture creates a baseline, compare evaluates a current page against a baseline, list enumerates baselines, and delete removes one. There is no overlap or ambiguity between the tools.
All tool names follow a consistent verb_noun pattern: capture_baseline, compare_visual, list_baselines, delete_baseline. The verbs (capture, compare, list, delete) are all distinct and describe the action clearly.
Four tools is an appropriate scope for visual regression testing, covering the essential operations of create, compare, list, and delete. Each tool earns its place without unnecessary bloat or missing core functionality.
The tool set covers the complete baseline lifecycle: capture (create/update), compare (use), list (read), and delete. The compare tool provides both statistics and visual output, enabling the agent to make informed judgments. No obvious gaps exist.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Capture screenshots, detect visual regressions between page versions, and analyze with AI.
AI QA that runs your app in a browser on every pull request: projects, test targets, test cases.
Browser-based QA for AI-built software. Test pages with real browsers via agents.
AI QA tester — real browsers scan sites for bugs, SEO, perf, and accessibility issues via chat.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/noGarne/visual-regression-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
