How to give Claude Code visual context of your running app

Claude Code is great at reading your codebase, but blind to what's actually rendered on screen. Here's how to give it eyes so it can debug UI issues without you copy-pasting a single screenshot.

The problem: Claude Code can read code but can't see

When you're debugging a layout bug or a CSS regression with Claude Code, the typical loop looks like this:

1. You describe the bug in words ("the button is cut off on the right").
2. Claude asks clarifying questions or guesses at the cause.
3. You screenshot the simulator or browser, drop the image into the chat, and paste it in.
4. Claude finally sees the issue and suggests a fix.
5. You apply the fix, screenshot again to verify, and paste it in again.

That middle step — manually capturing and uploading screenshots — is the bottleneck. Every UI iteration costs you ~30 seconds of friction. Over a long session, that's hundreds of tiny interruptions.

The fix: an MCP server that Claude Code can call itself

Claude Code supports the Model Context Protocol (MCP), an open standard for giving AI agents tools they can call. If you connect an MCP server that exposes a fetch_liveview tool, Claude Code can request a fresh screenshot on its own — the same way it already reads files or runs shell commands.

AppContext is an MCP server built exactly for this. It runs as a menu bar app on macOS and exposes tools that let Claude Code (and any other MCP client) capture live screenshots of your iOS simulator or web browser on demand.

An MCP server is one of several routes — Claude Code also has built-in computer use, and browser-only MCP servers cover web apps. If you're still choosing an approach, see our comparison of the four ways to let Claude Code see your app; the rest of this guide covers the MCP server setup.

Setup in three steps

1. Install AppContext

Download the universal macOS app from appcontext.dev. It's a notarized DMG; drag it to Applications and open. You'll see a small menu bar icon.

2. Add AppContext to Claude Code's MCP config

Claude Code keeps local- and user-scoped MCP servers in ~/.claude.json, and project-scoped servers in a .mcp.json file at the root of your project. The .mcp.json format is the one you'd check into version control:

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

Or let the CLI write it for you:

claude mcp add appcontext --transport sse http://localhost:7777/sse

Restart Claude Code and it'll pick up the server on startup.

3. Start coding

With AppContext running and your iOS simulator or web app open, Claude Code can now call fetch_liveview and fetch_recent_logs whenever it needs visual context. You don't have to prompt it — a good agent will call the tools automatically when you describe a visual bug.

What Claude Code can see

Five of AppContext's built-in tools cover the common visual-debugging workflows:

• fetch_liveview — returns a fresh PNG of your iOS simulator or the current Chrome tab. Claude sees exactly what you see.
• fetch_recent_logs — Metro bundler logs for React Native / Expo apps.
• fetch_web_console — browser console logs (errors, warnings, console.log output) from any open Chrome tab.
• switch_platform — flip between iOS and web context without reconfiguring anything.
• fetch_device_status — which platform is active and whether a simulator or browser is actually connected, so the agent can tell "nothing is running" apart from "the screen is blank".

Alongside those, AppContext registers get_browser_tabs plus the hub tools (hub_status, hub_call, hub_policies) covered in the personal MCP hub and authorization guides.

A concrete example: debugging a misaligned modal

Say you're working on an Expo app and a bottom-sheet modal is rendering halfway off the screen on iPhone 15 Pro. Old workflow:

1. Describe it to Claude.
2. Screenshot the simulator.
3. Paste the screenshot.
4. Wait for diagnosis.
5. Apply the fix.
6. Screenshot again.
7. Paste again.
8. Iterate.

New workflow with AppContext connected:

1. Tell Claude "the bottom-sheet modal on the settings screen is rendering off-screen."
2. Claude calls fetch_liveview, reads the Metro logs via fetch_recent_logs, identifies the missing SafeAreaView wrapper, edits the file.
3. After the hot-reload, Claude calls fetch_liveview again to verify. If it's still wrong, it iterates without waiting for you.

In practice this turns a 10-minute back-and-forth into a 60-second fix.

Does this work with other AI tools too?

Yes. AppContext speaks standard MCP, so any client that supports MCP works out of the box:

• Claude Code (this guide)
• Cursor — add via the Add to Cursor button on the AppContext homepage
• Claude Desktop — add to claude_desktop_config.json
• Windsurf and other MCP-compatible editors

You configure AppContext once and every AI tool you use gets the same visual context.

Privacy and control

Screenshots are captured locally on your machine and sent directly to the MCP client you've connected. Nothing passes through AppContext's servers. If you want to block specific tools from being called in specific contexts, AppContext also ships with per-tool authorization policies.

Frequently asked questions

Where does Claude Code store its MCP server configuration?

Local- and user-scoped servers live in ~/.claude.json in your home directory. Project-scoped servers live in a .mcp.json file at the root of the project, which you can check into version control. claude mcp add writes to whichever scope you pass with --scope.

Do I need to prompt Claude Code to take a screenshot?

No. Once AppContext is connected, fetch_liveview is a tool Claude Code can call on its own, the same way it reads files. Mentioning the tool once at the start of a UI session helps it form the habit for the rest of the session.

Does this work with AI coding tools other than Claude Code?

Yes. AppContext exposes a standard MCP endpoint at http://localhost:7777/sse, so any MCP-compatible client works — Cursor, Claude Desktop, Windsurf. You configure AppContext once and every connected tool gets the same visual context.

Do screenshots leave my machine?

No. Captures happen locally and are returned over localhost to the MCP client you connected. They do not pass through AppContext's servers. Login and subscription management use Supabase, but screenshot payloads stay local.