MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
UI Verify is a remote MCP server published at uiverify.ai. It has been probed 6 times since 9/12/2026. It answered in 6 of them (100.0%), a near-uninterrupted record. Median response time is 656 ms, a delay an agent will notice. It offers a narrow, focused set of 9 tools. On the protocol side it still runs 2025-11-25 and has not moved to the newer spec.
Can an LLM agent pick the right tool here — names, descriptions and parameter clarity are assessed.
render_diff_image — Parameter 'which' is ambiguous without context (e.g., 'baseline' vs 'candidate').list_build_stories — Shares similar naming with 'list_pr_stories', risking confusion in usage context.get_pr_changeset — Description is truncated, omitting critical context about its purpose.Risk: low
tools/list structure, inputSchema validity, and a functional smoke test — the components of the 0-100 score.
Tools the server advertised in the latest measurement — measured, not catalog-claimed.
list_buildsRecent UI Verify builds for your project, newest first. Each row is a one-line verdict (gateStatus: passed | changed | failed) for a commit/PR — use it to find the build to inspect. No image URLs or per-story detail here: call get_build for the changed-story list, get_diff for images.
branchstringstatusstringlimitintegerget_buildTriage one build, resolved by commitSha, prNumber, or buildId (exactly one). Returns the gate verdict and counts (total/changed/failed/unchanged), then the FIRST page (25) of the changed stories (story id, viewport, % pixels changed, review decision, the AI verdict aiVerdict=intended|regression + aiConfidence, and for a regression the judge's one-line aiFlagReason=what-looks-unintended, when AI review is on) and the first page of failed stories (failedStories[].kind is `render` when the story produced no frame, or `interaction` when it rendered and its play() assertion threw; failedStories[].error is the message's first line, errorTruncated marks the ones that carried more). When AI review ran, aiReview tallies how many changes look like regressions vs intended, and the changed list is ord
commitShastringprNumberintegerbuildIdstringlist_build_storiesPage through one build's stories filtered by status (resolved by commitSha/prNumber/buildId). Use it to read past get_build's first page, or to browse the unchanged/passed stories get_build only counts. status='changed' returns changed stories (same shape + order as get_build, regression-first); status='failed' returns failed stories; status='unchanged' returns the stories that did NOT change this build but have a baseline on this branch (storyId, viewport, browser) - fetch any of their images by storyId with get_diff or render_diff_image to confirm 'identical to baseline'. Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Unchanged is only available once the build has settled (an in-progress build has r
commitShastringprNumberintegerbuildIdstringstatusstringrequiredcursorstringlimitintegerget_pr_changesetThe cumulative 'this PR vs base' visual changeset (resolved by commitSha/prNumber/buildId) - what the whole PR does to the UI versus the branch it merges into, INDEPENDENT of what is left to review on the latest build. Unlike get_build (this commit vs the branch's own accepted baseline), this survives in-PR accepts: a story accepted mid-PR still shows under `changed` with status=accepted, so it answers 'what did this PR change' even after the gate reads clean. Returns base (the branch it merges into), counts {new,changed,removed,unchanged}, and the first page of `new` + `changed` + `removed` stories (storyId, title, name, kind, review status, aiVerdict). `removed` lists stories that HAD a baseline on the base branch but are gone from this PR's head (a deletion - otherwise invisible; each c
commitShastringprNumberintegerbuildIdstringlist_pr_storiesPage through the PR-vs-base changeset stories of one kind (resolved by commitSha/prNumber/buildId) - use it to read past get_pr_changeset's first page. kind='new' returns stories the PR adds that the base branch has no baseline for; kind='changed' returns stories whose image differs from the base branch's accepted image (even if accepted mid-PR, with status=accepted); kind='removed' returns stories that HAD a baseline on the base branch but are gone from head (a deletion; each carries lastBuildId, not a review status or verdict). Returns { stories, nextCursor }: pass nextCursor back as `cursor` for the next page; null means no more. limit defaults to 25 (max 100). Requires the PR visual changeset feature.
commitShastringprNumberintegerbuildIdstringkindstringrequiredcursorstringlimitintegerget_diffPer-story diff detail for a build (resolved by commitSha/prNumber/buildId). Returns diff metrics and presigned, time-limited URLs (download them to a file, or link them in a PR comment) for the baseline, candidate, and diff PNGs. Defaults to the changed stories; pass storyId for one specific story. When that storyId is an UNCHANGED story it returns its baseline (diffResultId null, changed false, the baseline URL as both baselineUrl and candidateUrl) - the story rendered identical to baseline. Use render_diff_image instead when you want the actual pixels inline for a vision model, not a URL. When AI review is on, each diff carries the judge's call: aiVerdict (intended|regression), aiConfidence, aiSummary (what changed), aiReasoning, and aiFlagReason; all null when AI review didn't run for i
commitShastringprNumberintegerbuildIdstringstoryIdstringrender_diff_imageFetch a story's image as an INLINE image (base64 pixels, not a URL) so a vision model can look at it directly. Needs a native MCP client that renders image content; piped through raw curl it is useless (use get_diff's URLs there instead). Two ways to address it: (1) diffResultId + which for a CHANGED story - which is baseline|candidate|diff (the triptych) or before_after, the baseline and candidate SIDE BY SIDE (before on the left, after on the right) cropped to the changed region - and when a story changed in SEVERAL far-apart places, one such crop PER region stacked top to bottom, so a header-plus-footer change is two tight crops, not a page-tall image. before_after is usually what you want for a code change - it zooms to what moved instead of a full page. Get diffResultId from get_build
diffResultIdstringwhichstringcommitShastringprNumberintegerbuildIdstringstoryIdstringreview_diffRecord a review on a single diff result (get diffResultId from get_build/get_diff). 'accept' makes the candidate the new baseline for that story on its branch, so the next build is clean; 'deny' records the rejection without changing the baseline; 'ignore' excludes the story from the gate persistently (the snapshot keeps differing on future builds but no longer flags the check) — use it for an intentional, ongoing diff like an animation or a live timestamp. This is the same accept/deny/ignore as the dashboard, attributed to your project key. Use after you've inspected the diff (e.g. with render_diff_image) and decided intended vs. regression.
diffResultIdstringrequireddecisionstringrequiredaccept_buildAccept ALL changed stories in one build at once (resolved by commitSha/prNumber/buildId), advancing each story's per-branch baseline so the next build is clean. This is the bulk form of review_diff='accept' — use it when you've decided the whole build's changes are intended. It accepts every changed story, including stories that already have a prior denied review; failed stories are unaffected. Returns the build triage after accepting (first page of changed stories, each now showing decision='accepted'; page the rest with list_build_stories if changedNextCursor is set).
commitShastringprNumberintegerbuildIdstringDerived by comparing consecutive probes — changes in era, protocol version, build and reachability.
Add this badge to your README — it updates automatically as measurements change.
[](https://mcpmetrics.io/servers/io-github-igrlk-uiverify)<a href="https://mcpmetrics.io/servers/io-github-igrlk-uiverify"><img src="https://mcpmetrics.io/badge/io.github.igrlk/uiverify/era.svg" alt="mcpmetrics"></a>You are seeing the last 7 days. Sign up for the full history. Which check failed and why is in the dashboard.
Sign up free to seeThe catalog entries whose name and description are closest to this one, found with the same index the search box uses.
Agent Interviews is an AI-powered research platform designed to conduct qualitative interviews an...
Let your AI agent hire a human for tasks it can't do — first post free.
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Read-only triage for n8n, MCP, webhook, and AI agent workflow production failures.
Yapp turns "build me a page and publish it" into a live URL. Connect once (browser OAuth, or a token for terminal clients) and your AI can publish a webpage from HTML, or host a PDF, image, or ZIP exactly as-is to a public `<slug>.yapp.page` URL in seconds, then update, password-protect, set expiry, attach a custom domain, or read form submissions, all by asking. Free to start; no local install. **Tools (15):** `publish_page`, `publish_file`, `update_page`, `delete_page`, `get_page_stats`, `list_my_pages`, `rename_page`, `change_page_slug`, `set_page_expiry`, `set_page_password`, `list_submissions`, `add_custom_domain`, `list_custom_domains`, `check_custom_domain`, `remove_custom_domain`.
Carrier MCP — natural language control of your MVNO/eSIM fleet. 52 tools (43 OCS API wrappers + 8 AI intelligence + 1 OCS event history), 5 prompts, OAuth 2.1 + PKCE. Streamable HTTP on Cloudflare Workers.
| Run | Era | Modern | ms | Legacy | ms | Versions |
|---|---|---|---|---|---|---|
| 2026-09-13 01:33:33 | Legacy | 400 | 673 | 200 | 564 | 2025-11-25 |
| 2026-09-12 23:31:36 | Legacy | 400 | 489 | 200 | 541 | 2025-11-25 |
| 2026-09-12 21:29:15 | Legacy | 400 | 540 | 200 | 656 | 2025-11-25 |
| 2026-09-12 19:27:29 | Legacy | 400 | 1746 | 200 | 1854 | 2025-11-25 |
| 2026-09-12 17:24:09 | Legacy | 400 | 557 | 200 | 583 | 2025-11-25 |
| 2026-09-12 15:21:42 | Legacy | 400 | 1105 | 200 | 2001 | 2025-11-25 |
Each block is one measurement round. Green: working response. Amber: responded but the server was returning errors (5xx). Red: no response at all.
Each cell is one probe run. Faded cells are incomplete probes — one leg did not answer, so the era is inconclusive.
The two probe legs separately: modern server/discover and legacy initialize.
Comments
Sign in to write a comment
No comments yet. Be the first.