Triage visual changes from your coding agent

If an agent wrote the pull request, an agent can review the visual changes. UI Verify exposes builds over the Model Context Protocol, so a coding agent - Claude Code, Cursor, or any MCP client - can pull a build's changes into the conversation, look at each diff, read the AI judge's reasoning, and accept the intended ones.

• List a build's changed stories, and on a passed build its unchanged ones too.
• Fetch a diff image and the AI judge's verdict for any story.
• Fetch a before and after cropped to the change - one crop per changed region when it moved in several places.
• See a story that did not change this build (identical to its baseline).
• Bucket changes into real regressions vs cosmetic reflow vs rendering noise.
• Summarize the real regressions into a PR comment with before/after images.
• Accept baselines in bulk once you have signed off on the direction.

Two tools return a story's images, for two different jobs. get_diff returns presigned URLs for the baseline, candidate, and diff PNGs - use these to download an image to a file or link it in a PR comment. render_diff_image returns the actual pixels inline, so a vision model can look at them directly.

Call render_diff_image with which: "before_after" for a changed story to get the baseline and candidate side by side, cropped to the changed region plus a little padding, so for a one-line change the agent sees what moved, not a full-page screenshot it has to scan. When a story changed in several far-apart places (a header and a footer, say), it comes back as one such crop per region stacked top to bottom, instead of one tall image spanning the gap between them.

On a passed build every story matched its baseline, so there is no diff to fetch. list_build_stories with status: unchanged lists those stories, and render_diff_image with a build selector and a storyId returns any story's current image - the candidate if it changed, otherwise the baseline it matched. That is how an agent confirms 'this component looks right, identical to baseline' even when nothing changed. See Baselines and branches.

Close the loop where the humans are. Once the agent has bucketed the changes, have it write one PR comment with the real regressions, a before and after image for each (link the baseline and candidate URLs from get_diff), and a link to the full build on the dashboard. A reviewer skims the comment instead of clicking through every story.

1. The agent opens the pull request and the UI Verify check runs.
2. The agent lists the build's changes over MCP.
3. It reads each diff and the judge's verdict.
4. It accepts the intended changes, and flags anything it cannot attribute to the diff for you to look at.

The bottleneck on an agent's pull request is verification, not authorship. Putting the diff and a verdict where the agent already works closes the loop: the same place the code was written is where its pixels get checked, with no context switch to a dashboard in the middle.