Best screenshot MCP servers for Claude Code and Codex (2026, compared)

You told Claude Code the toolbar was misaligned, and it grepped the repo for toolbar and edited the wrong component. It never saw your toolbar — your agent reads files, not screens. A screenshot MCP server closes that gap, and in 2026 there are enough of them that picking one is a genuine comparison problem: they differ on what they can see (browser tab, native window, iOS Simulator), whether they ship structured accessibility data alongside pixels, and how many tokens each look costs you.

We went through the repos and docs of every maintained option we could find. (Disclosure: we build SupaMaus Lite, which appears below as one row among peers — the table is useful with our row deleted.)

A screenshot MCP turns "look at my screen" from a copy-paste ritual into a tool call — but which screen it can see (browser tab, native window, or simulator) is the entire buying decision.

What a screenshot MCP actually gives your agent (and what it doesn't)

The MCP spec lets tool results carry text, base64 images, and resource links, so a screenshot server can hand your agent an image the same way grep hands it text. No more saving a PNG, dragging it into the terminal, and typing a paragraph about where to look — the agent asks, the server answers. That's the whole trick, and it's worth real minutes per bug. It's the practical half of what we call spatial context.

What it doesn't give you: understanding. A raw screenshot is expensive — Claude's vision docs put image cost at roughly (width × height) / 750 tokens, with a ~1,568px long-edge sweet spot. A 16" MacBook Pro's 3456×2234 Retina frame would be ~10,000 tokens if sent raw; Claude Code's built-in computer use (a research preview since March 2026) downscales it to ~1372×887, closer to 1,600 tokens per look — and that built-in option is worth knowing about before you install anything, though it's macOS-only and has its own trade-offs. And pixels alone don't tell the model what it's looking at: no element names, no bounds, no text that's scrolled out of view. That's why the accessibility-tree column below matters more than the screenshot one.

The comparison table: eight screenshot MCPs side by side

"Pointing" here means a human indicating a region or element to the agent — as opposed to the agent driving the mouse itself, which most of these do well and which is a different job.

| Tool | Platform | Captures | Accessibility tree | Pointing | Voice | Price | Best for | |---|---|---|---|---|---|---|---| | Playwright MCP | Anywhere Playwright runs | Browser only | Yes — AX snapshots are the default mode | No (agent-driven element refs) | No | Free, open source (Microsoft) | Browser automation and testing | | Peekaboo | macOS 15+ | Native (screen, window, menu bar) | Yes — structured JSON | No (agent-driven click/type/drag) | No | Free, MIT | Scripted macOS capture + automation | | macos-use | macOS 13+ | Native (AX diffs; optional window captures) | Yes — AX-first, sends only diffs | No (agent-driven) | No | Free, MIT | Fast text-first native automation | | ios-simulator-mcp | macOS + Xcode + idb | iOS Simulator (screenshots, video) | Yes — simulator AX info | No (agent-driven tap/swipe) | No | Free, MIT | Poking a running simulator | | XcodeBuildMCP | macOS 14.5+, Xcode 16+ | iOS Simulator + devices (video, logs) | Yes — semantic element refs | No (agent-driven) | No | Free, MIT | Build → run → automate pipeline | | Screenpipe | macOS, Windows, Linux | Native — 24/7 history, not just now | Yes — AX text with OCR fallback | No | Transcribes audio 24/7 (history, not commands) | Source-available; personal use free, app plans from $25/mo | Searchable screen history | | snap-happy | macOS (Linux/Windows "works on my machine") | Native (full screen; per-window on macOS) | No | No | No | Free, MIT | Zero-frills screenshots | | SupaMaus Lite | macOS 14+, Apple silicon | Native + iOS Simulator (+ browser via extension) | Yes — roles, bounds, identifiers, full window text | Yes — gesture trail (hold-to-mark) | Yes — on-device Whisper, aligned to the trail | $15 one-time (launch price, first 100 seats; then $50) | Human-pointed context ("this button, here") |

Every cell comes from the linked project's own docs or repo, checked July 2026. There's also a long tail of small single-purpose servers in the MCP directories — kazuph/mcp-screenshot (screenshot plus Japanese-focused OCR, MIT, minimally maintained) is representative — and some directory listings point at repos that no longer exist. Check the repo before you add anything to your config.

Web pages vs native windows: most screenshot MCPs can't see native apps

Search "screenshot mcp" in any directory and most hits are browser screenshotters — Playwright or Puppeteer wrappers that render a URL and return pixels. Useful, but they cannot see your terminal, Xcode, Figma, the iOS Simulator, or the Electron app you're debugging. If your bug lives outside a browser tab, a browser-based screenshot MCP will never see it, no matter how good it is.

Native capture is a different discipline. On macOS it means Screen Recording permission for pixels and Accessibility permission for structure, and the payoff for doing it properly is the AX tree: element roles, names, and bounds that survive compression in a way pixels don't. Peekaboo, macos-use, Screenpipe, and SupaMaus Lite all read it. One gotcha worth knowing: Electron apps don't build their accessibility tree until an assistive client asks, so tools that want structure from them have to set the AXManualAccessibility attribute first — documented Electron behavior, and a common cause of "the AX tree is empty" bug reports.

So the first question isn't "which screenshot MCP is best" — it's "where do my bugs live?" Browser-only work: the next section's answer is easy. Native and simulator work: your options narrow fast.

Best for browser work: Playwright MCP

For anything inside a browser, Playwright MCP is the answer, plainly. It's Microsoft-maintained, free, and its default mode doesn't send screenshots at all — it sends accessibility snapshots, "structured text output that LLMs parse naturally, ~200–400 tokens per snapshot vs thousands for DOM/screenshots," per its own docs. Forty-plus tools cover navigation, form filling, network mocking, tracing, and an optional coordinate-based vision mode.

The caveat is token economics when you leave snapshot mode. One engineer measured a single browser_take_screenshot call at 232,000 tokens, and a 2026 tooling comparison put a typical Playwright MCP session around 114K tokens. Stay in snapshot mode and it's cheap; lean on screenshots and it isn't. For reproducing user-reported bugs rather than driving the browser yourself, Jam takes a different angle: narrated browser recordings with video, console, network, and transcript exposed as layered MCP artifacts.

Best for macOS and iOS apps: Peekaboo, SupaMaus Lite, and the simulator pipeline

For scripted native capture — "screenshot the frontmost window, click Export, screenshot again" — Peekaboo is the strongest pick. It captures screens, windows, and menu bars pixel-accurately, returns AX data as structured JSON, and automates clicking, typing, scrolling, and drags, with background-targeted input so it doesn't steal your focus. MIT-licensed, installable via Homebrew, and actively shipped (v3.8.0 landed this week). If you want structure with almost no pixels, macos-use goes further: it reads the AX tree directly and sends only diffs — the elements that changed after each action — which its docs position as much faster than screenshot-driven loops.

Those are agent-driven tools: the model decides where to look. We build SupaMaus Lite for the inverse case — you know where to look and need to hand that knowledge over. Hold two keys, drag a highlight over the broken toolbar, mutter "this spacing, here," and the agent gets an annotated screenshot, the gesture trail, an on-device WhisperKit transcript aligned to it, and the AX elements under the trail with roles, bounds, and full window text. It's $15 one-time, macOS 14+ on Apple silicon, and honestly the wrong tool if you want unattended automation — pair it with Peekaboo rather than instead of it.

For iOS work there's a third lane: the simulator pipeline. ios-simulator-mcp (MIT, 2.1k stars, featured on the Anthropic engineering blog) gives the agent tap/swipe/type, screenshots, video, and accessibility inspection of a booted simulator. XcodeBuildMCP wraps the whole loop — build, install, launch, log capture, video, and UI automation with "semantic element refs from the view hierarchy" across 82 tools. And because the Simulator bridges the simulated app's accessibility elements into the macOS AX tree (provable with xctree), pointing at a SwiftUI view in the Simulator with SupaMaus resolves it — down to your own accessibilityIdentifier. We've written up the full simulator workflow separately.

Best for searchable history: Screenpipe

Everything above answers "what's on screen now." Screenpipe answers "what was on screen last Tuesday" — it records screen and audio 24/7 into a local SQLite database with full-text search, extracting text via the OS accessibility tree with OCR fallback, at a claimed 5–10 GB per month. Its MCP server lets Claude query your history and meeting transcripts. The core is source-available (free for personal, non-commercial use); the desktop app runs $25/month and up.

That's memory, not live context — a different tool for a different question. Recall ("what did that error dialog say yesterday?") wants history; debugging ("why is this dialog wrong?") wants a fresh, structured capture of the thing in front of you. Worth noting for anyone still on Rewind or Limitless: after Meta's acquisition of Limitless, screen and audio capture was disabled in December 2025, which leaves Screenpipe as the maintained open option in this lane.

Screenshots alone aren't enough

Whichever server you pick, don't stop at pixels. The OSWorld ablations put accessibility tree plus screenshot at 69.2–71.8% relative task success versus 56.4% for annotated screenshots alone — structure and pixels together beat either one. Frontier models have gotten genuinely good at looking (Claude Opus 4.8 scores 87.9% on ScreenSpot-Pro), but a screenshot still can't tell the model an element's role, its exact bounds, or the text scrolled out of view. The AX tree can.

That's the real dividing line in the table above, and it's why we'd rank a structure-aware server with mediocre screenshots over a beautiful screenshotter with none. The full argument is in accessibility trees vs screenshots.

Setup snippets for Claude Code and Codex

Claude Code, one command (Playwright MCP shown; swap the package for others):

claude mcp add playwright -- npx -y @playwright/mcp@latest

Codex reads MCP servers from ~/.codex/config.toml:

[mcp_servers.playwright]
command = "npx"
args = ["-y", "@playwright/mcp@latest"]

Servers that run as local apps register over HTTP instead — SupaMaus Lite, for example, listens on 127.0.0.1:19741 and ships an agents/install.sh that configures both Claude Code and Codex in one command (using a stdio bridge where a client lacks HTTP support). If you're on Codex specifically, the Codex screenshot workflow covers the end-to-end setup.

The short version: Playwright MCP for the browser, Peekaboo or macos-use for scripted native work, ios-simulator-mcp or XcodeBuildMCP for the simulator pipeline, Screenpipe for history, SupaMaus Lite when a human needs to point. Install the one that matches where your bugs live — and check the AX-tree column before the screenshot one.