Loading ToolBench
Standalone MCP server for SnapDiff. Exposes visual-diff, screenshot capture, change detection, and HTML-to-image tools to local agents (Claude Code, Cursor, Cline, Zed, Continue, ...) over stdio. Hits the public SnapDiff REST API; bring your own SNAPDIFF_API_KEY.
The SnapDiff MCP server demonstrates strong tool definitions with comprehensive descriptions and well-structured schemas. All 6 tools have detailed, LLM-optimized descriptions (150-400 chars range) explaining WHAT the tool does, WHEN to use it, and key prerequisites. Input schemas are fully typed with proper JSON Schema format. However, several critical patterns are missing: tool annotations (readOnlyHint/destructiveHint/idempotentHint) are not declared despite some tools being write-heavy; output schemas are not formally documented; and error handling lacks explicit recovery guidance. Parameter descriptions are excellent overall, though some lack specific constraints (e.g., threshold numeric ranges). The tool composition is sound, each tool has a single, clear responsibility and outputs are designed to chain (e.g., snapdiff_capture_baseline returns project/page_name for use in snapdiff_verify_ui_change).
Capture the current state of a page as the visual baseline for a SnapDiff project. Call this once per page before using snapdiff_verify_ui_change — the baseline is the reference screenshot that all future verifications diff against. For localhost URLs, the page is captured locally with a headless browser (no tunnel needed). For public URLs, the SnapDiff backend captures it. Returns when the baseline is confirmed in place.
Take a screenshot of a web page. Use this when you need to see what a webpage looks like right now — to inspect layout, verify rendering, or capture a baseline for later comparison.
Capture every page in the list and diff them all against their baselines in one build. Use this after editing a shared component or design token to check whether the change affected pages you did not directly modify. Returns a per-page summary of changed vs unchanged. If any page changed, a review URL is included so a human can approve or reject before the baseline moves.
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.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels (READ_ONLY, WRITE) in documentation but not registered with formal tool annotation hints that the MCP spec supports. snapdiff_capture_baseline and snapdiff_check_build are WRITE operations that should be flagged to prevent accidental execution.
Output schemas not formally documented in tool definitions. While responses are structured in code (see server.ts jsonResult calls), the tool registration does not include explicit outputSchema declarations. LLMs cannot infer what fields to expect (match, diff_percentage, before_image_url, etc.) without formal schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
Render HTML/CSS directly to an image. Use this to generate social cards, OG images, email headers, or any visual from code without needing a hosted URL.
Verify a UI change you just made matches what you intended. Use this whenever you modify a route, page, or component and need to confirm the visual result. Returns a verdict (`pass`, `expected_change_detected`, `unexpected_regression`, `no_change_detected`, or `needs_human_review`), a `next_action`, and a `review_url`. Always surface `review_url` to the user — it is the human-reviewable dashboard page showing the before/after/diff. Do not share raw image URLs (`diff_url`, `before_url`, `after_url`) — those are internal references. Requires a SnapDiff project + page baseline. Pass `intent` to describe in one sentence what you meant to change. For sharper verdicts, pass `intent_regions` with either a CSS `selector` (recommended for code-editing agents — SnapDiff resolves it to a bbox during capture) or a `bbox` directly (when your agent drives a browser and already knows pixel coordinates).
Error handling lacks recovery guidance. Tools return errorPayload() and errorResult() but source does not show structured error categories (retryable vs user-fixable vs fatal) or actionable next-step messages. For example, a failed baseline lookup should suggest 'Did you call snapdiff_capture_baseline first?' rather than a bare error.
Parameter constraints not always explicit. For example, 'threshold' (pixel sensitivity) accepts 0.0-1.0 but description does not state the numeric range. 'ignore_selectors' is an array but no maxItems or minItems constraints. 'width' and 'height' in snapdiff_html_to_image lack min/max bounds.
snapdiff_check_build returns a per-page summary but no pagination documented. If a project has 100+ pages, the response could be extremely large and blow context. No limit documented, no offset/cursor pattern shown.
snapdiff_verify_ui_change supports 'intent_regions' with bbox or selector, but the description does not clarify how the server resolves a selector. Does it run CSS queries on the after page? What happens if selector matches 0 or 100+ elements? No documented fallback behavior.