mcpbeat Sign in

UI Verify MCP Server

not responding

UI Verify is listed as active in the registry but did not answer our last check. It exposes 15 tools. Last commit 5 Nov 2026.

Visual testing for coding agents: your agent sees every UI change it makes and triages each diff.

Uptime history 65 days of history · worst day 0%
65 days agonow
0.0%
Uptime 24h
0 of 184 checks
15
Tools
read from the server
70 ms
Response time
average over 24h
27
Stars
last commit 5 Nov 2026

What changed 39

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

25 Oct 8 tool descriptions were rewritten delete_comment, get_pr_changeset, list_comments and 5 more
25 Oct a tool changed the parameters it asks for post_comment
18 Oct 10 tools changed the parameters they ask for accept_build, get_build, get_diff and 7 more
18 Oct 4 tool descriptions were rewritten delete_comment, list_builds, review_diff and 1 more
18 Oct a tool appeared list_projects
26 Sep 5 tool descriptions were rewritten accept_build, get_build, list_build_stories and 2 more
20 Sep a tool changed the parameters it asks for render_diff_image
18 Sep 5 tools appeared delete_comment, list_comments, post_comment and 2 more
18 Sep 2 tool descriptions were rewritten get_build, get_diff
18 Sep a tool disappeared get_change_attribution
and 1 more, back to 8 September 2026

What the code does

We read the source, 3 d ago · tools taken from the live server · rules 995398eba69f

Capabilities

What this server is able to do. For an MCP server this is often the job itself — a terminal server runs commands because that is what it is for. Listed so you know what you are plugging in, not as an accusation.

        const child = Bun.spawn(

Is this your server and something here is wrong? Tell us — corrections are free and do not require a plan.

This code can reach further than it looks

We found places where it runs commands, builds paths or queries from values it is given. None of that is a flaw by itself — it becomes one when the code changes, and code changes quietly between releases. We re-read it on every one.

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 2 min ago.

run in your terminal
claude mcp add uiverify --transport http https://uiverify.ai/api/mcp
Settings → Connectors → Add custom connector, then paste this address
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
{
  "servers": {
    "uiverify": {
      "type": "http",
      "url": "https://uiverify.ai/api/mcp"
    }
  }
}

This server publishes 1 more address. The block above uses the one we reach during checks; the full list is under Endpoints below, and the author may intend a particular one for your client.

Available tools 15

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 story's own review-comment tally comments {total, unresolved}) 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'). comments is the build-wide review-comment tally {total, unresolved}: unresolved>0 means a designer/QA (or another agent) left an open note on a story - read it with list_comments BEFORE you accept. 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, each with its comments {total, unresolved}; unresolved>0 means an open review note - read it with list_comments 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).
comment
delete_comment
Soft-delete a comment (get its id from list_comments). An agent can delete only agent-authored comments, never a human's. Deleting a thread root removes its replies too.
update_comment
Replace the body of a comment (get its id from list_comments). An agent can edit only agent-authored comments, never a human's. Reference: https://uiverify.ai/docs/mcp-tools
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). Refused, with nothing accepted, while any changed story has an unresolved review comment: the error names those stories; read them with list_comments, address each note, resolve_comment its thread, then accept again.
builds
list_builds
Recent UI Verify builds for one 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.
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.
comments
list_comments
Every review comment on a build's changed stories (resolved by commitSha/prNumber/buildId), each carrying its diffResultId, author (human name or 'agent'), body, createdAt, and anchor - where on the candidate image it points: null (whole diff), {type:'point',x,y}, {type:'rect',x,y,w,h}, or {type:'path',points,closed}, all normalized 0..1 to the candidate image. Use it to read what a designer/QA (or another agent) flagged on a screenshot before acting.
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. Each diff also carries comments {total, unresolved} for THAT story - unresolved>0 means an open review note; read the thread with list_comments before accepting.
post
post_comment
Leave a review comment on one of a build's changed-story diffs (resolve the build by commitSha/prNumber/buildId, target the diff by diffResultId from get_build/get_diff). The comment is authored as the agent. Optionally anchor it to a spot on the candidate image with `anchor`: omit or null for a whole-diff comment, {type:'point',x,y} to pin a point, {type:'rect',x,y,w,h} for a box, or {type:'path',points:[{x,y},...],closed} for a shape - all coordinates 0..1 normalized to the candidate image. `side` picks the pane ('after' the candidate, default; 'before' the baseline). Pass `parentId` (a root comment id from list_comments) to REPLY in that thread instead - a reply inherits the root's side and carries no anchor, so `anchor`/`side` are ignored. A new root comment is refused when a newer build exists on the branch (comment on the latest build); replies stay allowed. Reference: https://uiverify.ai/docs/mcp-tools
projects
list_projects
Every UI Verify project you can access, across all the teams you are a member of, most recently built first. Each row carries the projectId to pass to list_builds, or to a commitSha/prNumber lookup, when you can access several projects, plus the team and project slugs, name, type (storybook | playwright | vitest | bun | screenshot), repo, and lastBuildAt. Calls that take a buildId, diffResultId, or commentId never need a projectId. When you aren't in any project yet, it lists UI Verify's demo project instead (demo: true): every read tool works on it, so you can show what UI Verify does on a real build, but nothing can be accepted or commented there. Every response about the demo carries a note saying so. When the list is empty, note says how to get a first project.
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). When the story has unresolved review comments, a text note saying so comes with the image: read them with list_comments before you accept.
resolve
resolve_comment
Mark a comment thread resolved or reopen it (get the id from list_comments). Resolving stamps the thread ROOT, so pass a root comment's id - a reply id is a no-op. Any team writer may toggle this.
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 the agent (and to you, when you logged in). Use after you've inspected the diff (e.g. with render_diff_image) and decided intended vs. regression. accept and ignore are refused while the story has an unresolved review comment (read it with list_comments, address it, resolve_comment the thread, then retry); deny is always allowed.
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).

Tools removed

Tools this server used to expose. Anything built against them stopped working on the day they went.

get_change_attribution
removed 19 Sep 2026

Endpoints

URLTransportStateLatencyChecked
https://uiverify.ai/api/mcp streamable-http answering 70 ms 2 min ago
https://uiverify.ai/mcp streamable-http answering 71 ms 2 min ago

Alternatives to UI Verify

same job, measured the same way
Agent Verify
by ai-blockchain-ventures

Security checks for AI agents and MCP configs: 124 tested checks, from your AI coding assistant.

315 installs/wk local only
Splera
by sohaibt

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

59 installs/wk local only
Kijito
by kijito

Shared memory and mail for your AI agents. Verified with Claude Code; other MCP clients in testing.

answering
Notify
by notifycx

Transactional email for coding agents: send, test, verify domains, webhooks, logs.

428 installs/wk local only
DiffCI
by diffci

Fail-closed, change-aware verification for AI coding agents with affected-test guidance.

3 tools answering
Enoki
by enokilabs

Test your AI agents for security and safety weaknesses, and re-verify the fixes.

answering
Argus — Testing for Coding Agents
by chriswu727

Testing MCP for coding agents: exercise real user journeys, find bugs, verify them with evidence.

1 114 installs/wk local only
GemBoss
by gemboss

Build, test and measure ecommerce pages and stores. Every change waits as a draft for your approval.

answering

UI Verify — questions

Answers built from our own checks of this server.

What can UI Verify do?
It exposes 15 tools, read directly from the server on our last check. Among them: accept_build, delete_comment, get_build, get_diff, get_pr_changeset, list_builds and 9 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 →
What is UI Verify mostly used for?
Its tools cluster around comment and build. That is what this server is built to work with — the grouping comes from the actual tool names, not from a category we assigned.
Is UI Verify working right now?
We send a real MCP handshake every 15 minutes. Over the last 24 hours 0 of 184 checks got a reply (0.0%), average response time 70 ms. The bar chart above shows every period we have measured.
Did UI Verify ever remove tools?
Yes. get_change_attribution is no longer exposed — we recorded the date each one disappeared. A tool vanishing usually means a breaking change for anything that depended on it.
The registry lists UI Verify as active — why does it not respond?
The official MCP registry stores what the author submitted; it does not verify that the server still runs. We check the endpoint ourselves, and this one does not answer. Catalogues that copy the registry without checking will show it as working.
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 in the form 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 15 of them are readable on this page. This is what we observed, not what the docs claim.
Is UI Verify open source?
The code is open source: it is published under the MIT licence, written in TypeScript, 27 stars on GitHub and 2 open issues. The licence covers the code in the repository, not the hosted service at uiverify.ai, which runs on its operator's own terms.