Review a user interface with screenshots and an AI assistant
Visual interface review is most useful when a particular rendered state is hard to describe in words: a simulator screen, a stale-looking page, a responsive layout, or a frontend change. Share what you expected to see, which app and state are on screen, and what changed since the last capture. A screenshot can help discuss visible spacing, labels, clipping, and hierarchy. It does not expose the page structure or replace interaction and accessibility checks.
Name the state and expected behavior
Describe the route, screen, viewport or device size, relevant user action, and the expected result. If the issue is stale content, say what should have changed and how you triggered the update. Include the exact text or error in chat when possible. For a simulator, identify the screen and build or test state; the assistant cannot infer hidden application state from pixels alone.
A reference screenshot or design can provide a baseline. Explain whether you want a comparison of alignment, spacing, clipping, labels, hierarchy, or a particular component, rather than asking broadly whether the interface looks good. These are visual review questions; a screenshot does not run a visual regression test.
Share the smallest useful screen area
On desktop, start a screen share and select the relevant tab or application window through the browser chooser. A tab or window usually contains enough context while limiting unrelated material. Check that the selected source displays the correct state, then ask for one screenshot. For a physical mobile interface, a phone camera can capture the device, though a direct screenshot or simulator export usually preserves more detail.
Hide unrelated private content before sharing and keep the capture page open. The selected view can change as you navigate, but a later state reaches the assistant only through another capture request. Verify the current preview after reloading the app; if it shows the wrong window, select the intended source yourself. A fresh capture does not repair a client's stale attachment cache or expose a remote desktop that is not visible locally.
Review a change as a before-and-after
Ask the assistant to identify visible differences from the baseline and distinguish observation from interpretation. Then make one code or design change yourself and render the same route at the same viewport. Capture the updated state and ask whether the original visible issue remains. Keep the prompt focused on a decision such as whether a button is clipped, two elements are misaligned, spacing changed, or an error message is noticeable. This is a human-requested before/after review, not automated screenshot comparison or regression detection.
If a page appears stale, note the refresh or navigation action and the expected data state. A screenshot can reveal that the old content remains visible, but it cannot tell whether caching, application state, or a failed request caused it. Use browser developer tools, logs, and network details to establish the cause.
Pair screenshots with automated checks
Screenshots do not reveal DOM semantics, keyboard behavior, screen-reader names, focus order, hidden content, or all responsive breakpoints. Use accessibility inspections, component tests, browser automation, and direct DOM or console evidence for those questions. A rendered image is supplementary visual feedback, not a substitute for a regression suite or a structured design review.
If the thing to inspect is already a saved image or design file, attach that file directly when your assistant supports it. Use screen capture for an on-screen state that needs shared context, then keep code, test output, and exact measurements in their native text form.
Set up without starting a capture
Set up your MCP client with the full tool reference. The separate capture page can replace the active capture page for your account. It does not take a photo by itself. When your source is ready, try:
Example to adapt: Take one screenshot of the selected [app window/tab] at [route or screen and viewport]. I expected [state] after [action], but see [symptom]. Compare with [reference/baseline]; check [alignment, clipping, spacing, labels, or hierarchy] and list only observable differences. Do not claim a regression from one still; identify what needs DOM, accessibility, interaction, or test evidence.