MCP server for iOS simulator screenshots and web browser debugging

AppContext is an open MCP endpoint that gives your AI coding agent live visual access to what you're building. iOS simulator or Chrome browser, one server, one connection string.

Why a dedicated MCP server for this?

AI coding agents like Claude Code, Cursor, and Windsurf are fluent at reading files, running commands, and editing code. The one thing they can't do natively is see your app. That's a real gap when you're debugging layout bugs, visual regressions, or user-flow issues.

The Model Context Protocol lets AI agents call external tools. So the fix is a tool that takes a screenshot and returns it. AppContext is that tool, wrapped in a native macOS app with the plumbing already handled: iOS Simulator bridging, Chrome DevTools Protocol connection, permissions, and licensing.

What AppContext exposes over MCP

fetch_liveview

Returns a PNG of the currently-selected platform. In iOS mode, this uses xcrun simctl io booted screenshot to grab a fresh capture of the booted simulator. In web mode, it connects to a running Chrome instance (started with --remote-debugging-port=9222) and captures the active tab.

The screenshot is returned base64-encoded in the MCP tool response, so the AI agent sees it inline — no file download, no staging step.

fetch_recent_logs

Streams recent output from the Metro bundler (React Native / Expo apps). The AI gets the same stack traces, warnings, and console.log output you see in your own terminal.

fetch_web_console

For web apps, this returns the Chrome DevTools console buffer: errors, warnings, logs, with timestamps. Useful when the AI needs to see a runtime exception that only shows up in the browser, not in the terminal.

switch_platform

Flips the context between iOS and web. You can also switch from AppContext's menu bar UI; the MCP tool is there so AI agents can switch themselves when they need to.

get_browser_tabs

Lists open Chrome tabs so the AI can pick the right one if you have multiple dev servers running (e.g. localhost:3000 and localhost:5173 both open).

fetch_device_status

Reports which platform is active and whether a simulator or browser is actually connected. This is the tool that lets an agent distinguish "nothing is running" from "the screen really is blank" before it starts guessing at a fix.

iOS support: the details

AppContext works with any iOS simulator booted from Xcode, including React Native and Expo apps running in Expo Go or a dev client.

• Screenshot source: xcrun simctl io booted screenshot — the same tool Xcode uses internally.
• Metro logs: AppContext hooks into the Metro bundler process to capture structured log output.
• Hot-reload loop: because the screenshot is fresh on every call, the AI can verify its own fix after Metro hot-reloads.

Android support via adb is on the roadmap.

Web support: the details

AppContext uses the Chrome DevTools Protocol (CDP) via puppeteer-core to talk to your browser. That means no browser extension to install and full compatibility with any Chromium-based browser (Chrome, Edge, Brave, Arc).

• Launch command: open -a "Google Chrome" --args --remote-debugging-port=9222 --user-data-dir="$HOME/.chrome-appcontext" on macOS. The --user-data-dir part is not optional on current Chrome (see below).
• Tab selection: AppContext lists open tabs and remembers your choice.
• Console buffer: includes errors, warnings, logs, and network failures.
• Works with any framework: React, Vue, Angular, Svelte, plain HTML — AppContext doesn't care what rendered the page.

Connection string

AppContext runs a local Server-Sent Events (SSE) endpoint at http://localhost:7777/sse. Every MCP client configures it the same way — and the type field matters, since Claude Code reads a url entry with no type as a stdio server and skips it:

{
  "mcpServers": {
    "appcontext": {
      "url": "http://localhost:7777/sse",
      "type": "sse"
    }
  }
}

How it compares to alternatives

The short version is below; for a fuller decision framework that also covers Claude Code's built-in computer use and the official browser MCP servers, see the four ways to let Claude Code see your app.

BrowserTools MCP

BrowserTools MCP (AgentDeskAI) is a popular community project — about 7,300 GitHub stars — that provides similar web-screenshot and console-log functionality via a browser extension. It works, but development has been quiet: the last tagged release is v1.2.0 from March 2025, and commits since then have been documentation changes rather than code (checked August 2026). It also requires installing an extension, and it doesn't cover iOS. AppContext ships as a single signed macOS app with both platforms built in, and talks to Chrome over the DevTools Protocol rather than through an extension.

Generic screenshot MCP servers

There are a handful of single-tool MCP servers on GitHub that wrap puppeteer.screenshot(). They work for taking a screenshot of a random URL, but they don't connect to your running dev environment, don't see your local state, and don't capture console logs or Metro output.

iOS-focused MCP servers

Several actively maintained projects wrap the iOS toolchain for MCP clients, and they're worth knowing about because they solve adjacent problems:

• XcodeBuildMCP (now maintained under the Sentry organisation) is build- and project-centric — building schemes, running tests, managing simulators — and also exposes simulator screenshots.
• ios-simulator-mcp is a focused wrapper around simulator interaction and inspection.
• mobile-mcp covers mobile automation and scraping across iOS and Android.

Those are UI-automation and build tools that happen to expose a capture. AppContext is built around the capture loop itself: a fresh screenshot on every call, Metro and browser console logs beside it, the same endpoint for web, and the hub and policy layer over every other MCP server you use — in one signed macOS app rather than a per-project npx entry. If what you need is "drive the simulator" or "build and test from the agent", one of the projects above is likely the better fit, and nothing stops you running it as an upstream server inside AppContext's hub.

Privacy and data flow

AppContext runs entirely on your machine. Screenshots are captured locally and sent over localhost to your MCP client. They do not pass through any remote server. Login and subscription management use Supabase, but screenshot payloads stay local.

Frequently asked questions

Why does Chrome ignore --remote-debugging-port?

Since Chrome 136, the remote-debugging switches are ignored when pointed at Chrome's default profile directory. Pair the flag with a non-default profile, for example --remote-debugging-port=9222 --user-data-dir="$HOME/.chrome-appcontext". AppContext's own "Launch Chrome with Debugging" action uses its own profile directory and isn't affected.

How does AppContext capture an iOS simulator screenshot?

It shells out to xcrun simctl io booted screenshot, the same mechanism Xcode uses, and returns the PNG base64-encoded in the MCP tool response so the agent sees it inline.

Does AppContext support Android?

Not today. AppContext currently covers the iOS Simulator and Chromium-based browsers on macOS. Android support via adb is on the roadmap and is not shipped.