mcpbeat Sign in

UI Verify MCP Server

answering

UI Verify is answering right now. Last checked 13 min ago. It exposes 10 tools. Last commit 16 Sep 2026.

MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.

Uptime history 14 days of history · worst day 0%
14 days agonow
2.2%
Uptime 24h
2 of 91 checks
10
Tools
read from the server
592 ms
Response time
average over 24h
22
Stars
last commit 16 Sep 2026

What changed 1

Every tool that appeared, vanished or quietly changed what it asks for. Recorded since 8 September 2026. No other catalogue keeps this.

8 Sep a tool appeared get_change_attribution

UI Verify does not always answer

Over the last week it answered 1.4% of our checks. We check every 15 minutes, so you hear about the next outage within the hour — not from your users.

Three servers free · no card

Connect this server

Endpoint below is the one we actually reach during checks — not the one copied from a README. Last verified 13 min ago.

run in your terminal
claude mcp add uiverify --transport http https://uiverify.ai/api/mcp
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "uiverify": {
      "url": "https://uiverify.ai/api/mcp"
    }
  }
}
~/.codex/config.toml
[mcp_servers.uiverify]
url = "https://uiverify.ai/api/mcp"
.cursor/mcp.json
{
  "mcpServers": {
    "uiverify": {
      "url": "https://uiverify.ai/api/mcp"
    }
  }
}
.vscode/mcp.json
{
  "mcpServers": {
    "uiverify": {
      "url": "https://uiverify.ai/api/mcp"
    }
  }
}

Available tools 10

Read directly from the server with tools/list, grouped by what they act on. If a tool disappears, we record the date.

build
get_build
Triage 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 ordered likely-regressions-first. changedNextCursor / failedNextCursor are non-null when there are more than 25: page the rest with list_build_stories. counts.unchanged is how many stories did NOT change and have a baseline - this triage call does NOT list them (keeps the response lean); call list_build_stories status=unchanged to browse them (e.g. to confirm a passed build's stories are 'identical to baseline'). No image URLs here - call get_diff or render_diff_image for pixels.
list_build_stories
Page 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 rendered nothing, so it returns an empty page).
accept
accept_build
Accept 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).
builds
list_builds
Recent 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.
change
get_change_attribution
Per-story change attribution for a build (resolved by commitSha/prNumber/buildId): for each CHANGED story, the PRs and authors that landed between the story's baseline and this build. Built for the nightly-on-main triage workflow, where a build spans many merges and a per-PR build's free author attribution is unavailable. Returns { stories: [{ storyId, base (the baseline commit), refs: [{ prNumber, author, commitShas }], truncated, partial }] }. refs with prNumber null are direct pushes attributed to author; author null means the commit matched no GitHub account. truncated=true means the range exceeded the host's commit ceiling and refs is a prefix; partial=true means GitHub was unreachable and refs is best-effort. A story with an empty refs and neither flag genuinely had nothing between its baseline and head. No image URLs - fetch pixels by storyId with get_diff / render_diff_image. Requires the change-attribution feature.
changeset
get_pr_changeset
The 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 carries lastBuildId, the build that rendered its now-orphaned baseline). newNextCursor / changedNextCursor / removedNextCursor page the rest with list_pr_stories. No image URLs - fetch pixels by storyId with get_diff / render_diff_image. Requires the PR visual changeset feature.
diff
get_diff
Per-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 it.
render
render_diff_image
Fetch 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 (changedStories[].diffResultId) or get_diff. (2) a build selector (commitSha|prNumber|buildId) + storyId for ANY story's current image - the candidate if it changed this build, else its baseline. This second form is the only way to see an UNCHANGED/passed story's pixels (list them via list_build_stories status=unchanged), so you can confirm 'identical to baseline'. Errors if the image doesn't exist (a genuinely new story has no baseline, so no before_after either).
review
review_diff
Record 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.
stories
list_pr_stories
Page 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.

Endpoints

URLTransportStateLatencyChecked
https://uiverify.ai/api/mcp streamable-http answering 753 ms 13 min ago

Alternatives to UI Verify

same job, measured the same way
Dungbeetle
by dungbeetle

Visual regression & snapshot testing for AI agents — list runs, read semantic diffs, review.

42 installs/wk local only
Splera
by sohaibt

A/B testing for vibe coders: create, track, and ship experiments from your AI coding agent.

20 installs/wk local only
Sentinel DV
by kiranreddi

MCP tools for UVM/cocotb logs, coverage, regressions, and waveform triage.

78 installs/wk local only
Regex Lab
by ryudi84

MCP server for regex testing, matching, replacing, and validation

local only
Localstack MCP Server
by localstack

A LocalStack MCP Server providing essential tools for local cloud development & testing

209 installs/wk local only
I
Elias MCP Sample Server
by elpadev

A sample MCP server for testing

81 installs/wk local only
Lastest
by las-team

Run visual regression tests, review diffs, and manage baselines on a Lastest instance.

37 installs/wk local only
I
CTnP MCP Server
by jitsmaster

Ingeniux CTnP MCP server for personalization, A/B testing, and audience management.

local only

UI Verify — questions

Answers built from our own checks of this server.

What can UI Verify do?
It exposes 10 tools, read directly from the server on our last check. Among them: accept_build, get_build, get_change_attribution, get_diff, get_pr_changeset, list_builds and 4 more. The full list with descriptions is on this page — we take it from the server itself via tools/list, not from a README. How MCP servers expose tools in the first place →
Is UI Verify working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 2 of 91 checks got a reply (2.2%), average response time 592 ms. The bar chart above shows every period we have measured.
How do I connect UI Verify?
Copy the ready config from this page — we generate it for Claude Code, Claude Desktop, Codex, Cursor and VS Code, each with the file path that client actually reads. It is a remote server, so there is nothing to install — the client connects to the address.
Does UI Verify need an API key?
No. UI Verify completed a full MCP handshake with us as an anonymous client and listed its tools without asking for anything. All 10 of them are readable on this page. This is what we observed, not what the docs claim.
How fast is UI Verify?
It answers our handshake in 592 ms on average, which is faster than 22% of all working MCP servers we measure. That is on the slow side — worth knowing if the tool sits inside an interactive loop. The comparison comes from our own checks across the whole registry, every 15 minutes.
Is UI Verify open source?
Yes — it is published under the MIT licence, written in TypeScript, 22 stars on GitHub and 1 open issue. The source link is on this page, so you can read exactly what it does with your data before you connect it.