Scopo is an MCP server now

Your agent knows your repo better than you do. It can find the function, trace the call, write the patch. Then you ask it "put the logs next to the editor" and it has nothing. No eyes on your screen, no hands on your windows. The whole physical layer of your work is invisible to it.

Scopo already models that layer. It knows every window, which Space each one lives on, which display, which project a Space belongs to, which browser tab is open where, and what your saved layouts look like. This release hands that model to agents: Scopo runs a local MCP server, and any MCP client on your Mac can use it.

Two minutes to wire up

Agent access is off by default. You turn it on explicitly:

defaults write com.scopo.app agentAccessEnabled -bool true

Then relaunch Scopo. (A Settings toggle and a per-client approval dialog are coming; today the switch is the Terminal command, which suits the audience for this feature.)

Now point a client at it. Scopo ships its own MCP server inside the app binary. No npm package, no separate install, nothing to keep in sync with the app.

Claude Code:

claude mcp add scopo -- /Applications/Scopo.app/Contents/MacOS/Scopo --mcp-stdio

Cursor, Claude Desktop, or anything else with a JSON config:

{
  "mcpServers": {
    "scopo": {
      "command": "/Applications/Scopo.app/Contents/MacOS/Scopo",
      "args": ["--mcp-stdio"]
    }
  }
}

Ask your agent "where am I?" to confirm. You should get back something like this:

{
  "active_profile": "work",
  "current_space": {
    "name": "scopo",
    "space_id": 3,
    "project_id": "034C2957-…",
    "display": "9F221282-…",
    "window_count": 5,
    "is_current": true
  },
  "focused_window": {
    "app": "Ghostty",
    "title": "scopo · zsh",
    "window_id": 137,
    "space_id": 3,
    "on_current_space": true,
    "frame": { "x": 1280, "y": 78, "w": 1272, "h": 994 }
  },
  "spaces_total": 7
}

That's the whole setup.

The 14 tools

They come in four groups: look around, find things, move things, remember things.

Tool	What it does
get_context	Where the user is: focused window, current Space and project, display, profile. The orientation call.
list_spaces	Every Space across every display, with window counts and which one is current.
list_windows	Windows on this Space (default), a named Space, or all of them: id, app, title, display, frame, state.
find	Fuzzy-resolves a phrase the way you'd say it ("the scena space", "my terminal", "safari") to ranked candidates with ids.
find_files	Semantic file search over Scopo's on-device index. Describe the file by meaning, not name.
focus_window	Focus a window by id, switching Space if it lives elsewhere.
focus_tab	Jump to a browser tab or a native app tab, raising its window and switching Space as needed.
switch_space	Go to a Space by session id or stable id.
move_window	Send a window to another Space. follow: false moves it without disturbing your view.
gather	Pull a set of windows into the current Space. The "bring my terminals here" verb.
list_workspaces	Saved tiling layouts: name, origin project, saved-at.
save_workspace	Snapshot the current Space's tiling layout under a name.
restore_workspace	Re-apply a saved layout onto the current Space. (Pro.)
command	Experimental. See below.

A few design decisions that matter once an agent is actually driving:

Actions verify themselves. The macOS APIs underneath return Void and fail silently: a raise that didn't raise, a Space switch that got eaten. Every action tool polls the real state afterward and reports verified: true/false. Your agent finds out that the move didn't take, instead of confidently telling you it worked.

Two kinds of id. space_id is a per-session integer, fine inside one conversation. project_id and space_uuid are stable across restarts and reboots, so those are what you use in anything the agent saves for later, like a script or a skill.

Ambiguity is a result, not a guess. find returns ranked candidates. Several strong ones mean the agent should ask you or pick from context. The tool description says so, which is why agents don't silently act on the wrong window. Failures come back as a readable code (gone, ambiguous, feature_locked) rather than a wall of text.

What it actually feels like

The interesting part isn't any single tool, it's that your agent now closes the loop between code and screen:

• "Set me up for the licensing bug." Scopo restores the saved layout, gathers the right terminal, and opens the Space where that project lives.
• "Move everything that isn't this project off my screen." list_windows, then move_window with follow: false on each, and you never see a flicker.
• "Which Space has the Netlify dashboard?" find with types: ["tab"], then focus_tab.
• "Find the datacenter security PDF and open it next to my notes."

Agents are good at the boring multi-step version of these. That's the point.

The same tools, in Shortcuts

Everything above also exists as Apple Shortcuts actions, so you don't need an agent to get value out of it. Thirteen actions ship in the Shortcuts library: Switch to Space, Focus Window, Bring Window Here, Move Window to Space, Gather Windows Here, Jump to Tab, Save Workspace, Restore Workspace, Where Am I, Find Files, Get Windows, Get Spaces, Get Workspaces.

They're not a parallel implementation. Every one of them routes through the exact same tool kernel as MCP, gated by the same agentAccessEnabled switch. A Shortcut that switches Spaces and a Claude Code call that switches Spaces run identical code.

Experimental: the command tool

The fourteenth tool takes plain English and figures out the rest. You pass the user's words verbatim ("bring my terminal here", "switch to comms") and an on-device model maps them onto one of the other tools and runs it.

Treat this one as experimental. It needs macOS 26 and Apple Intelligence, and it will be wrong sometimes. It's built the careful way. The model does guided generation over a fixed set of tool calls and never executes anything itself, and it's given the real names of your Spaces and windows before it generates, so it copies vocabulary that exists instead of inventing it. Even so: if your agent already knows the ids, the explicit tools are faster and more reliable. command exists for the case where nobody has resolved anything yet.

Privacy and security

Scopo's rule hasn't changed: window titles and thumbnails never touch disk, and nothing leaves your Mac. The agent surface doesn't bend that.

• The server is a unix domain socket in your Application Support folder, mode 0600, and every connection is peer-checked against your own uid. Not a network port. Nothing on your LAN can reach it.
• Scopo itself never sends any of this anywhere. What your MCP client does with the tool results is that client's business. If you point a cloud agent at it, window titles go where that agent goes. That's your call to make, which is exactly why the switch is off until you turn it on.
• The stdio shim is a dumb relay. All protocol logic lives in the app, so it can never drift out of sync with the tools. It also survives Scopo restarts, reconnecting on its own through updates and crashes instead of leaving your agent with a dead server for the rest of the session.

Where it goes next

The obvious gap is consent: a Settings pane and a per-client approval dialog, so turning this on isn't a Terminal command and so you can see which clients are connected. Tiling verbs are next after that. An agent that can restore_workspace but can't say "split these three side by side" is missing the move you'd reach for most.

If you build something with it, I want to hear about it. Download Scopo, flip the switch, and let your agent see your desk.