Skip to main content
Glama

snapdiff_compare_pages

Compare two web pages visually to detect UI differences. Supports ad-hoc comparison with two URLs or baseline comparison against stored page baselines.

Instructions

Visually compare two web pages to detect differences. Use this to verify that a code change didn't break the UI, compare staging vs production, or check if a page changed. Captures both pages as screenshots, runs pixel-level comparison, and returns a diff percentage plus a highlighted diff image showing exactly what changed. This is the primary tool — use it whenever you need to verify visual output.

Two modes:

  1. Ad-hoc compare: pass before + after URLs.

  2. Baseline compare: pass after URL + project (slug or ID) + page_name. Compares against the last-accepted baseline for that page on the project's default branch. Use this when the user has set up a SnapDiff project and you want to verify a page still matches its approved state.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
afterYesURL of the "after" page (e.g. staging URL or localhost) — the page to check
beforeNoURL of the "before" page to compare against. Omit when using baseline mode.
projectNoProject slug or ID for baseline mode. When set with page_name, diffs against the stored baseline.
page_nameNoPage name within the project (e.g. "homepage", "pricing"). Required for baseline mode.
branchNoBranch name for baseline lookup. Defaults to the project's default branch.
thresholdNoPixel sensitivity 0.0-1.0. Lower = more sensitive. Default 0.1
ignore_selectorsNoCSS selectors to exclude from comparison (e.g. timestamps, ads)
full_pageNoCompare full scrollable pages. Default false
Behavior4/5

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

With no annotations provided, the description takes the full burden. It explains the process (captures screenshots, pixel-level comparison, returns diff percentage and highlighted image) and the two modes. It does not disclose potential side effects (e.g., storing screenshots) or return format details, but covers the main behavior.

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?

The description is efficiently structured with a clear opening sentence, bullet points for modes, and every sentence adds necessary information. It is front-loaded with the core purpose, making it easy to scan.

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?

Given the tool's complexity (8 parameters, two modes, no output schema), the description covers the essential aspects: modes, parameter usage, default behavior (branch defaults to default branch), and output (diff percentage and image). It could be more explicit about the exact return format, but overall it is complete.

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 100%, so baseline is 3. The tool description adds value by explaining the two modes, which connects how parameters like `before`, `project`, and `page_name` are used together. This context goes beyond individual parameter 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?

The description clearly states the tool's purpose: 'Visually compare two web pages to detect differences.' It lists specific use cases (verify code changes, compare staging vs production) and explicitly identifies itself as 'the primary tool' for visual verification, distinguishing it from its siblings.

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 provides clear usage context: 'use it whenever you need to verify visual output' and explains two modes (ad-hoc and baseline) with conditions for each. However, it does not explicitly state when not to use this tool or suggest alternatives beyond implying it is the primary one.

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/corralimited/snapdiff-mcp'

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