uisight

Your AI can already see the screen. It just can't measure it.

Screenshots make an agent guess: "that heading looks a bit faint." uisight makes it know:

- from a screenshot:  "the heading looks a little washed out, maybe adjust the color?"
+ from uisight:       INVISIBLE TEXT 1.04:1 — span.bg-gradient-to-r "your headline"
+                     (text rgba(255,255,255,.5) / bg rgb(247,247,248))

One is an impression. The other is a measurement with a selector attached — the agent fixes that element instead of hunting for it.

uisight is an MCP server for web and responsive UIs (Claude Code, Cursor, Antigravity, anything that speaks MCP). It runs live mobile + desktop sessions side by side, measures what it finds, and puts you and the agent in front of the exact same screen.

Built by a solo founder who got tired of taking phone screenshots, pasting them into chat, and typing "the button looks broken, can you see it?"

The live panel: desktop + mobile sessions of the same site, URL-synced. Inspect runs on every screen; findings come back per device. Your AI sees this exact view through MCP.

What makes it different

The measurement engine is the heart: instead of your AI burning tokens squinting at screenshots, inspect returns findings like

[mobile · Pixel 7 · light] https://yourapp.com/
  INVISIBLE TEXT 1.04:1 — span.bg-gradient-to-r "your headline" (text rgba(255,255,255,.5) / bg rgb(247,247,248))
  BUTTON a.text-white "Get Started" → text/background contrast 3.35:1
  touch target below 44px 180x23 — "read the guide"

Text findings are cheap, precise, and directly actionable — your AI fixes the exact selector instead of guessing.

"My agent already does this"

Fair — and partly true. Computer use, browser tools and most agent harnesses can already open a page and take a screenshot. That's the part uisight doesn't try to replace. Three things are still missing:

1. Looking isn't measuring. A vision model reading a screenshot cannot tell you a contrast ratio. It can't tell 4.6:1 (fine) from 4.3:1 (fails WCAG AA) — they look identical. It won't notice that a tap target is 41px instead of 44px, or that an element renders identically in light and dark mode because its color is hard-coded. uisight computes these from the live DOM: alpha-composited backgrounds, gradient text, oklch() colors and all.

2. The same price buys far more. This used to claim a screenshot costs several times what a measurement does. Measured, that is not true: a mobile frame is ~460 tokens and the matching inspect result is ~570. inspect is not the cheap option — it is the option that says 4.38:1 (threshold 4.5) where a picture only lets the model guess.

The real saving is a different choice: uisight <url> writes a report the model reads once (~800 tokens), while driving the MCP tools screen by screen re-sends the whole conversation at every step. Someone put the problem perfectly under the launch thread: "it burns some tokens but it manages." What it costs has the whole table, because a claim like this one is worth checking.

3. Nobody's watching with you. In the usual setup the agent looks at the page alone and reports back. Here you both watch the same live session — you see what it does as it does it, and when you spot something, you pin it (📌) with a note and the agent reads your note plus that exact frame. No more describing a bug in words.

Scope note: uisight is for web and responsive UIs. For native iOS/Android app control, Argent is excellent and does far more than we do there.

Quickstart

# one-shot audit: PNGs + gallery + report for iPhone/Pixel/desktop, light+dark
npx uisight https://yourapp.com --theme both

# live panel: mobile + desktop side by side, you browse, AI watches (and vice versa)
npx -y -p uisight uisight-panel http://localhost:3000

First run. Playwright ships its driver over npm but downloads browsers separately, so the first run has nothing to drive. In a terminal, uisight offers to fetch what it needs (~150 MB, once) and shows the download. Where there is nobody to answer — CI, or a panel an editor or agent host started — it never asks and never downloads; it names the exact command instead. UISIGHT_NO_INSTALL=1 turns the offer off everywhere, and you can always do it yourself:

npx playwright install chromium        # add webkit for the real iOS Safari engine

The one-shot audit produces a device × theme gallery with findings per card:

Hook it into your AI (MCP)

# Claude Code
claude mcp add --scope user uisight -- npx -y -p uisight@latest uisight-mcp

For Cursor / Antigravity / other MCP hosts, add to your MCP config:

{ "mcpServers": { "uisight": { "command": "npx", "args": ["-y", "-p", "uisight@latest", "uisight-mcp"] } } }

Then just tell your agent: "look at my app with uisight". The panel server starts automatically when needed.

MCP tools

Turkish tool names available with UISIGHT_LANG=tr (ekrani_gor, denetle, ...).

The panel (human side)

npx -y -p uisight uisight-panel <url> opens a browser page at localhost:5055:

• Mobile + desktop side by side, both live, URL-synced
• Click = tap on that device · wheel = scroll · type after clicking
• Per-pane device switcher, shared light/dark toggle
• Inspect button runs the measurement engine on every screen
• 📌 Pin: type a note, pin it — your AI reads note + screenshot via marks. No more "let me describe what I'm seeing."

Works inside VS Code / Antigravity via Simple Browser: Show → http://localhost:5055.

What it checks

Can you read it

• Invisible text (contrast < 1.6:1) and WCAG AA contrast failures — alpha-composited backgrounds, gradient text, oklab()/oklch() colors all handled
• Text below 12px, images without alt
• Text cut off by its own container (line-clamp and friends are not "clipped" — they are a decision)

Can you reach it

• Touch targets below 44px (mobile profiles only; inline text links exempt by width, per WCAG)
• Controls painted over by something else — confirmed with elementFromPoint, not geometry, and sampled edge to edge so a floating button covering one end of a wide button is caught
• Controls trapped under a fixed bar, or under the on-screen keyboard (keyboard-audit opens the keyboard the way a phone does and re-measures)
• Content clipped by a container with no way to scroll to it — the same box with overflow-x: auto is fine, because the content is reachable
• Text sliding behind a control when a row does not wrap
• Horizontal overflow with the offending elements
• Fixed bars sitting under the notch or home indicator — only when the page asked for the full screen (viewport-fit=cover) and then never used the inset it got back; without that flag iOS letterboxes the page and nothing can be hidden

Does it make sense

• A row of actions where every one looks identical, so nothing says which is primary — quiet on tabs, menus and filter chips, and only fires when mis-clicking costs something (save, delete, send, pay)
• Light patches left behind in dark mode
• Two languages in one screen, and US date formats in a non-US locale
• "0 results" shown while a spinner is still turning — an intermediate state presented as the truth
• An error message that names nothing ("An error occurred.") with no way out beside it
• An irreversible action — delete, remove, delete account — on a page that owns no confirmation step at all; the button is never clicked, because clicking it really deletes
• A permission asked for during load, before the person has done anything that would explain it
• Theme drift: elements identical in light and dark = likely hard-coded colors
• Console/JS errors and failed network requests per device

Every check has a false-alarm test next to its detection test. That is not politeness: a tool that cries wolf on every bottom navigation bar gets ignored, and then its real findings go unread too.

And the honest limit: automated checks cannot see design mistakes — a collided header measures fine. That's why see_screen exists and why the report says