DEV Community: ChairmanKaga

How to Manage MCP Servers in One Place on Mac

ChairmanKaga — Mon, 31 Aug 2026 16:43:17 +0000

If you run Claude Code, Cursor, Claude Desktop, and Codex, you already know the problem: the same MCP servers configured four times, four copies of the same API keys, and a server you disabled in one client still running in the other three. A handful of native Mac apps now exist to make that "one place." They don't all mean the same thing by it.

To manage MCP servers in one place on a Mac, you install a native app that owns your MCP configuration instead of hand-editing a JSON file per client. The apps that do this split into two architectures, and which one you want depends on what "one place" means to you.

Full disclosure: I build AppContext, one of the hub-style options below. The config-switcher apps are genuinely the better pick for some setups, and I'll say where.

Two ways to manage MCP servers in one place

Config switchers keep one master list and write it into each client's config file for you. Add a server once, tick which clients get it, and the app updates Claude Code's, Cursor's, and Codex's files. At runtime nothing changes — every client still opens its own direct connection to every server. The app is where you manage servers, not where the traffic flows.

Hub endpoints (gateways/proxies) run the servers themselves and expose one address. Point every client at that single endpoint and the hub fans out to the real servers behind it. Now "one place" is literal: one connection per client, one process that sees every tool call — which is what makes governance possible.

Both kill the four-JSON-files problem. Only the second gives you a single choke point where you can block a dangerous tool or rate-limit a chatty one.

The Mac apps, compared

App	Type	Price	macOS	Notable
MyMCP	Config switcher	Free, open source (MIT)	15.0+	Menu bar; browses the MCP registry; installs to multiple clients at once
MCP One	Config switcher	Free; $17.99 lifetime IAP	13.0+	Server "clusters"; marketplace; App Store; 100% local
MCP Orchestrator	Hub endpoint	Free beta	15.0+	One endpoint; background daemon; SKILL.md deployment; native Swift
AppContext	Hub endpoint	Free (Pro adds governance + live view)	Universal	Per-tool authorization policies; iOS Simulator + browser live view

All four are macOS-only today.

Config switchers: stop editing JSON, keep direct connections

MyMCP is the one to try first if free and open source matters. It's an MIT-licensed macOS 15+ menu bar app: browse the official MCP registry, install servers to multiple clients simultaneously, one-click enable/disable with status at a glance.

MCP One is similar with a nicer distribution story — Mac App Store, macOS 13+, free with an optional $17.99 lifetime unlock. Its angle is grouping servers into "clusters" you switch between, updating your agents' MCP files across Claude Code, Cursor, Claude, Codex, Windsurf, and Roo Code.

Both do exactly what they promise. The ceiling is architectural: because they write per-client configs, each client still talks straight to each server. There's no shared layer to enforce a policy at. If all you want is to stop hand-editing JSON, that ceiling never bothers you.

Hub endpoints: one connection, and a place to enforce rules

MCP Orchestrator is a native-Swift macOS 15+ app in free beta that runs a login-time background daemon and has you point Cursor, Claude Desktop, Claude Code, and Codex at it — "one config instead of many," plus SKILL.md playbook deployment and a tool preview.

AppContext is the other hub, and where it diverges is the two things a single choke point unlocks that a config switcher structurally can't:

Per-tool authorization policies. Every call passes through the hub, so you can block an individual tool — a filesystem delete_file, a GitHub create_repository — and the agent gets a POLICY_BLOCKED error instead of doing the thing. Blocklist mode (up to three tools) is free; unlimited blocks, allowlist/default-deny mode, and per-tool rate limits are Pro.
Live visual context. fetch_liveview returns a fresh capture of your iOS Simulator or a Chrome tab, plus Metro and browser console logs, so an agent can verify its own UI change instead of asking you to screenshot it. Pro feature, macOS-only. No other app in this comparison does visual context at all.

Trade-offs, plainly: AppContext is macOS-only, and the two headline extras — unlimited policies and live view — are Pro. Aggregating servers behind one endpoint, importing them from your existing clients, and blocking your first few dangerous tools are free.

Setting up the hub approach

One-time setup. Import your existing servers from Claude Code, Cursor, or Claude Desktop in the app, then point each client at the single local endpoint:

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

Restart the client and every aggregated tool shows up under one connection, namespaced by server (e.g. filesystem:read_file).

Which should you pick?

Just want to stop editing four JSON files: a config switcher. MyMCP (free/OSS) or MCP One (App Store, clusters).
Want one real connection per client: a hub — MCP Orchestrator or AppContext.
Want to restrict what your agents can do: a hub with policies — AppContext's home turf.
Building mobile/web UIs and want the agent to see its own work: AppContext adds live view of the iOS Simulator and browser.
On Windows or Linux: none of these yet — all macOS-native.

"Manage MCP servers in one place" turns out to be two different products wearing one search query. If the pain is config sprawl, a switcher solves it for free. If you also want a single point where you can see and gate every tool call — and, for app developers, give the agent eyes — that's a hub.

How to Let Claude Code See Your App While Coding

ChairmanKaga — Mon, 31 Aug 2026 16:36:10 +0000

If you've ever watched an agent confidently "fix" a layout bug it has never actually looked at, this one's for you. Here are the four ways to give Claude Code eyes on your running app — and which one fits which stack.

To let Claude Code see your app while coding, connect a tool it can call to capture what's actually rendered: a browser MCP server for web apps, a live-view MCP server for the iOS Simulator and browser tabs, or Claude Code's built-in computer use for everything else. Once one of these is connected, Claude checks its own work after every change instead of relying on your descriptions of what's on screen.

We build AppContext, one of the options below, so we're not a neutral party — but the honest answer to this question depends on what kind of app you're building, and for some stacks the right tool isn't ours. Here's the current landscape, followed by what the automated see-edit-verify loop actually looks like once it's running.

Why Claude Code needs a way to see your app

Claude Code reads your files, runs your build, and edits your components, but it has no idea what any of that renders to. It can write plausible CSS and still ship a button clipped off the right edge of the screen, because “compiles cleanly” and “looks right” are different facts.

Anthropic's own best-practices guide for Claude Code is blunt about the fix: “Give Claude a check it can run: tests, a build, a screenshot to compare. It's the difference between a session you watch and one you walk away from.” For logic, the check is a test suite. For UI, the check is visual — and if the agent can't capture it on its own, you become the verification loop. Every regression waits for you to notice it, screenshot it, and paste it into the terminal.

Everything below is a way to hand that job to the agent.

The four ways to let Claude Code see your app

Approach	What it can see	Requirements	Best for
Manual screenshots	Anything you capture yourself	None	One-off questions
Browser MCP server	Web apps in a browser it controls	Node.js; free	Web frontends
Computer use	Your whole screen	macOS; Claude Pro/Max plan	Native apps, GUI-only tools
Live-view MCP server	iOS Simulator + Chrome tabs, plus logs	macOS; live view is a Pro feature	React Native / Expo + web

1. Paste screenshots by hand

The baseline. Claude Code accepts pasted images, so you can screenshot the simulator or browser and drop the image into your prompt. It works for anything, costs nothing, and is fine for occasional questions. The problem is who does the capturing: you, on every iteration. The agent can't re-check its own fix, so the loop never closes without you standing in the middle of it.

2. A browser MCP server (web apps)

For web frontends there are two free, officially maintained options. Chrome DevTools MCP, maintained by the Chrome DevTools team, gives the agent a Chrome instance it can navigate, screenshot, and inspect — console messages, network requests, and performance traces included. Playwright MCP, from Microsoft, leans on accessibility-tree snapshots — structured text the model reads directly — with screenshots as a secondary tool.

Both are excellent at what they cover, and what they cover is a browser they launched: your web app, yes; your iOS Simulator, your Metro terminal, or a native window, no.

3. Claude Code computer use (anything on screen)

Claude Code now ships computer use as a built-in MCP server you enable from the /mcp menu. It's the broadest option: Claude can launch apps, click, type, and screenshot anything on your display, including the iOS Simulator or a native macOS app. It's also the heaviest. It's a research preview, macOS-only in the CLI, requires a Pro or Max plan, hides your other apps while it works, and takes a machine-wide lock so only one session can use it at a time.

Anthropic's docs are upfront about where it sits in the tool hierarchy: Claude tries the most precise tool first, and “if you have an MCP server for the service, Claude uses that.” Screen control is the fallback for things nothing else can reach — not what you want firing on every iteration of a CSS tweak.

4. A live-view MCP server (iOS Simulator and web, with logs)

This is the gap AppContext fills. It's a macOS menu bar app that gives AI coding agents live visual context over MCP: fetch_liveview returns a fresh capture of the iOS Simulator or a Chrome tab you pick, fetch_recent_logs streams Metro bundler output for React Native and Expo apps, and fetch_web_console returns browser console logs. No browser takeover, no screen lock — the agent grabs exactly the surface it needs in one tool call and keeps working. The trade-offs, stated plainly: it's macOS-only, and live view is a Pro feature (the MCP Hub side of the app is free).

If you're all-in on Expo specifically, the official Expo MCP is also worth a look: it adds screenshots, tap automation, and element inspection for Expo SDK 54+ projects with a running dev server.

What the automated loop actually looks like

Here's the workflow shift, using a bug class we hit constantly in React Native work: a bottom sheet renders behind the tab bar on one screen. Without visual access, you describe it in words, Claude picks one of three plausible z-index theories, and you paste a fresh screenshot between every attempt.

With a live-view tool connected, the prompt changes shape:

The bottom sheet on the settings screen renders behind the tab bar.
Fix it, then fetch the live view and confirm the sheet is on top.
Check the Metro logs if anything throws.

And the session runs like this:

Claude calls fetch_liveview and sees the broken state directly — no description tax, no guessing which theory matches reality.
It pulls fetch_recent_logs, checks for warnings from the sheet library, and edits the component.
Metro hot-reloads. Claude calls fetch_liveview again and compares against what it saw before.
Still wrong? It iterates without waiting for you. Fixed? It shows you the final capture as evidence instead of asserting success.

The load-bearing phrase in that prompt is “then fetch the live view and confirm.” You're giving the agent the check, not just the task — exactly the pattern the best-practices doc pushes. Once the tool exists, one sentence turns any UI request into a self-verifying one. Agents often reach for the tool unprompted after the first use; early in a session, a nudge helps.

The same loop covers web work. Switch AppContext's platform to a Chrome tab and the identical prompt pattern handles a layout regression in a Next.js app, with fetch_web_console standing in for Metro logs when something throws at runtime.

Which one should you pick?

Pure web app, Claude Code only: start with Chrome DevTools MCP or Playwright MCP. Free, official, and purpose-built for the browser.
React Native or Expo on the iOS Simulator: a live-view MCP server. Browser MCP servers can't see the Simulator, and computer use is too heavyweight to fire on every iteration. This is AppContext's home turf — simulator captures and Metro logs in the same session. Expo MCP is a solid alternative if your project is Expo SDK 54+.
Native macOS apps or GUI-only tools: computer use is the only option on this list that can see them at all.
More than one agent (Claude Code plus Cursor, Windsurf, or Claude Desktop): favor plain MCP servers over client-specific features. Computer use and the Claude Desktop preview pane are Claude-only; an MCP server works in every client that speaks the protocol.

Connecting it to Claude Code

The AppContext setup is two steps — the full walkthrough lives in our Claude Code visual context guide. Install the app from appcontext.dev, then register the local endpoint:

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

Restart Claude Code and the tools appear in /mcp. With your simulator or dev server running, ask for any UI change plus a “verify it” clause and watch the loop close on its own.

One connection, every agent

The quiet advantage of the MCP route is that nothing about it is Claude Code-specific. Cursor, Windsurf, and Claude Desktop speak the same protocol, so the same local endpoint gives every agent you use the same eyes. AppContext also works as a personal MCP hub, so your visual-context tools and the rest of your MCP servers ride one connection per client instead of a config file per tool — with per-tool authorization policies deciding what each agent is allowed to call.

The difference between an agent you supervise and one you can walk away from on UI work is a check it can run itself. Give Claude Code a way to see your app — whichever of the four fits your stack — and the screenshot-paste treadmill goes away.

FAQ

Can Claude Code see my screen without any setup?

No. Out of the box, Claude Code only sees what you paste into the prompt. To let it capture your app on its own you need to enable its built-in computer use (macOS, Pro or Max plan) or connect an MCP server that exposes screenshot tools, such as Chrome DevTools MCP for web apps or AppContext for the iOS Simulator and browser tabs.

Can Claude Code take screenshots of the iOS Simulator?

Yes, three ways: run xcrun simctl io booted screenshot yourself and paste the image; enable Claude Code's computer use and let it drive the Simulator window; or connect a live-view MCP server like AppContext so the agent fetches a fresh simulator capture in a single tool call, alongside Metro bundler logs.

What's the difference between computer use and an MCP screenshot server?

Computer use is general screen control: it can see and click anything, but it's a research preview, hides your other apps while working, holds a machine-wide lock, and requires a Pro or Max Claude plan. An MCP screenshot server exposes one purpose-built tool call that returns a capture of a specific surface without taking over your screen. Claude Code's own docs recommend using an MCP server when one exists and reserving screen control for what nothing else can reach.

Does the same setup work with Cursor and Windsurf?

If you go the MCP route, yes. MCP is an open standard, so a server like AppContext configured once works in Claude Code, Cursor, Windsurf, and Claude Desktop alike. Client-specific features such as Claude Code's computer use or the Claude Desktop preview pane don't transfer to other agents.

Is any of this free?

Chrome DevTools MCP and Playwright MCP are free and open source. Claude Code's computer use requires a Claude Pro or Max plan. AppContext's MCP Hub is free; its live view for the iOS Simulator and web is a Pro feature, and the app is macOS-only.

Configure MCP servers once for Claude Code, Cursor, and Windsurf

ChairmanKaga — Mon, 31 Aug 2026 16:36:06 +0000

If you run more than one AI coding tool, you've done this: added an MCP server, then added it again, then added it a third time. No client reads another client's config. Claude Code, Cursor, and Windsurf each keep their own file in their own place.

There are exactly two ways out — sync one canonical block into every file, or run a local hub that every client points at once. Here's the map first, then the tradeoffs.

Where each tool actually keeps its MCP config

As of August 2026, from each vendor's current docs:

Tool	Config file	Top-level key
Claude Code — user scope	`~/.claude.json`	`mcpServers`
Claude Code — local scope (default)	`~/.claude.json`, nested under the project path	`mcpServers`
Claude Code — project scope	`.mcp.json` in the project root	`mcpServers`
Cursor — global	`~/.cursor/mcp.json`	`mcpServers`
Cursor — project	`.cursor/mcp.json`	`mcpServers`
Windsurf (Cascade)	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`
Claude Desktop (macOS)	`~/Library/Application Support/Claude/claude_desktop_config.json`	`mcpServers`

They all use mcpServers, which is why copy-paste mostly works — and why this problem looks smaller than it is.

Four ways the copies drift

1. Claude Code resolves duplicates by precedence and doesn't merge. Local beats project beats user, and the winning entry is used whole — fields are not merged across scopes. Rotate a key in your committed .mcp.json while a stale local-scoped entry with the same name sits in ~/.claude.json, and the stale one silently wins. claude mcp list shows what actually resolved.

2. Remote-server key names differ. stdio servers are fine everywhere (command + args). Remote is where it breaks: Claude Code and Cursor use url, but Windsurf's documented example uses serverUrl. Paste a Cursor block into Windsurf and it may just not connect.

3. Transport names are moving. Claude Code's docs now say the SSE transport is deprecated, use HTTP where available. It also takes streamable-http as an alias for http. Old configs keep working but stop matching the docs.

4. Every client pays for every server, with different budgets. Windsurf's docs state Cascade has a limit of 100 total tools at any given time. Claude Code instead warns above 10,000 tokens of MCP output and caps at 25,000 by default (MAX_MCP_OUTPUT_TOKENS). One chatty server added to four files pushes on four different limits.

Option 1: sync a canonical block

Keep the master mcpServers block in dotfiles and write it into each client's file. Costs nothing, works fine. Two honest limits: you own the sync forever including the per-client key differences above, and nothing changes at runtime — four clients still spawn four copies of every stdio server.

Option 2: one endpoint

A personal MCP hub is itself an MCP server, but instead of exposing its own tools it connects to your upstream servers and re-exposes theirs behind one address. Each client gets exactly one entry, forever. Tools get namespaced (filesystem:read_file) so two servers that both define search don't collide.

I build AppContext, a macOS menu bar app that does this — it serves its endpoint at http://localhost:7777/sse. Concretely:

Get existing servers in. The Servers tab imports from Claude Code (~/.claude.json), Claude Desktop, and Cursor (~/.cursor/mcp.json), and discovers project .mcp.json files. Windsurf isn't an import source today, so anything living only in mcp_config.json gets added by hand.

Point each client at it. Claude Code, at user scope:

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

AppContext serves SSE today, so that's the right flag even though Claude Code labels SSE deprecated in favour of HTTP.

Cursor, in ~/.cursor/mcp.json:

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

Windsurf, in ~/.codeium/windsurf/mcp_config.json — different key:

{
  "mcpServers": {
    "appcontext": {
      "serverUrl": "http://localhost:7777/sse"
    }
  }
}

Then delete the old direct entries. Skipping this is the worst of both worlds — every tool exposed twice, once direct and once namespaced.

The part that's actually useful

One endpoint means every tool call from every client passes through one place. Blocking an individual tool — the destructive filesystem call, the repo-creating GitHub tool — applies to every client at once instead of being re-done per client, and the free tier covers up to three blocks in total across all your servers. Beyond three, allowlist mode and per-tool rate limiting are Pro. Blocked calls return POLICY_BLOCKED to the agent rather than failing silently.

Caveats

A hub is a component between your agents and your tools. If it's not running, no client has MCP tools — versus per-client configs, where a broken config only breaks one tool.

AppContext is macOS-only today. It serves SSE rather than Streamable HTTP. And it has no audit log or activity dashboard yet — you can block and rate-limit calls, but you can't review a history of what was called.

If you only use one AI coding tool, don't bother: edit the one file. Once you're maintaining the same list in two or more places, the copies will drift, and the only question is whether you'd rather own a sync script or a single endpoint.

Full version with sources: appcontext.dev/blog/configure-mcp-servers-once-claude-code-cursor-windsurf