MCP is the Platform

The IDE is one client. The MCP server is the product.

When most teams think about how an AI tool reaches users, they start with the surface: the editor pane, the chat window, the mobile app. The product is what the user clicks on. The protocol underneath is plumbing.

We've been building o8 the other way. The product is the protocol. The MCP server — the one your installed o8 app ships and the one a Claude Desktop install or a third-party agent can connect to — isthe platform. The desktop webview, the mobile inbox, and even the orchestrator's own webview tools are all just clients of the same server. They have the same level of access and the same level of restriction that anyone else who speaks the protocol has.

We don't need to be everyone's editor. We need to be everyone's control plane.

That inversion is the second-order moat. The first-order moat is the substrate (the Brain, see Note 01) and the orchestrator + workhorse seam (Note 02). Those make the product work for agents inside o8. The MCP-first design is what makes the product work for the harnesses we don't ship — a Claude Desktop session, a terminal Claude Code session, Cursor running our MCP plugin, a third-party autonomous agent. All of them can drive an o8 fleet through the same governance layer that protects you when you're tapping the inbox on your phone. The control plane accepts other harnesses as input.

One operator MCP server in the middle. Equal clients on the spokes.

The shape that matters is that all four clients in the figure are equal. The o8 webview running inside the Tauri app does not have privileged access to the operator server. It connects through a unix socket at /tmp/tauri-mcp-o8-<user>.sock. Claude Desktop connects through stdio after registering the server in its config. A Claude Code CLI session opened in this directory picks up the server automatically via the repo-root .mcp.json. A third-party agent can connect through either path.

From the operator server's point of view, every connection is a client running the same protocol. The same toolset is exposed; the same permission middleware applies; the same governance gates are enforced. There is no “native surface” that bypasses the rules.

One small consequence: most of o8's desktop UI was built by writing the MCP tool first and then calling it from the webview. That meant the moment a feature shipped, the same feature was also reachable from any other MCP client. We didn't add MCP support; the product was MCP support from the beginning.

Four groups of tools. Eighteen verbs. Same surface for every client.

The chat + approval group is the everyday loop. An agent connected via MCP can read the orchestrator's active state (o8_status), send a message into a chat session (o8_send), approve or reject the diff currently waiting at gate G4 (o8_approve / o8_reject), or pull the recent history.

The mission dispatch group is where real work happens. A packet gets created with create_mission, dispatched to a worker runtime with dispatch_mission, polled via get_mission_status, reviewed with submit_review, and merged via approve_and_merge. This is the same five-call sequence the desktop UI runs when you dispatch a packet by hand — literally the same calls.

The webview control group is the seven verbs that drive the installed o8 app from outside it: screenshot, snapshot, click, type, read, eval, navigate. They route through the Tauri unix socket. This is what lets Claude write tests, dogfood regressions, and verify a UI fix landed in the actual prod build — without us writing a Cypress wrapper. The observation surface is the protocol surface.

The Brain group exposes the substrate as MCP tools. An agent can ask the Brain a question and get back cited facts without writing any retrieval code. This is how the orchestrator itself queries the substrate during planning, and it's how a third-party agent can inherit the operator's organizational memory the moment it connects.

Standards win. We picked the one that's shipping.

We didn't invent a custom protocol because there was no reason to. MCP — Anthropic's Model Context Protocol — is the spec that the major model providers and the model-adjacent tools have aligned on for talking to external systems. Claude Desktop ships with MCP support. Claude Code CLI ships with MCP support. The third-party agent ecosystem that's grown up over the last year has standardized on it. Not perfectly — the spec is still moving — but well enough that betting on it costs us nothing and aligns us with where the agent ecosystem is heading.

• Stdio transportmeans we don't have to run a server on a port. The MCP client launches us as a subprocess and pipes JSON-RPC over stdin/stdout. That maps cleanly to the local-first model where everything runs on the user's machine.
• Unix socket transportfor the webview control plugin keeps the connection inside the user's machine without exposing any network port. The Rust side of the Tauri sidecar listens on the socket; the operator MCP server connects to it; nothing crosses the loopback boundary.
• Schema-first tool definitions mean every tool documents its inputs, outputs, and side effects to the client. An agent that has never seen o8 before can introspect the toolset and figure out what it can do without reading our docs.
• No vendor lock. Any client that speaks MCP can connect. We're not betting on Anthropic, OpenAI, or any single provider being the winner of the model fight. We're betting on the protocol being where they meet.

Picking a protocol that's already winning isn't strategy. It's table stakes. The strategic decision is building everything on top of it instead of around it.

The MCP server ships inside the o8 app. No separate install.

A common pain in MCP servers today is distribution. The server is a Node script. The user has to clone it, install dependencies, configure their MCP client to launch it. Friction at every step. Most setups never get past it.

o8 sidesteps that entirely. The operator MCP server is bundled with the app via esbuild as a single ESM file under out/server/ in the signed Tauri bundle. The Tauri sidecar sets O8_BUNDLED_MCP_PATH + O8_BUNDLED_MCP_DIRat launch. When you go to Settings → MCP and click “install for Claude Desktop,” we write a config to ~/Library/Application Support/Claude/claude_desktop_config.json (or ~/.claude.json) that points at the bundled binary inside o8.app. The user's Claude Desktop session then launches our MCP server the next time they open it.

The config writer is merge-preserving with a .o8-backup-<ts>sidefile. We don't blow away whatever else the user had configured. The setup surface in Settings → MCP is how a non-technical operator gets a Claude Desktop integration in two clicks.

Same shape for the cortex-mcp-server, which exposes fleet/issues/PRs/approvals/agents tools internally to orchestrator Claude Code sessions. Both servers bundle, both servers register through the same config writer, both servers are versioned with the app.

Seven tools that let Claude drive the app it's building.

The webview control group is the part of the toolset most people miss when they look at o8 from outside. It's also the part that makes the development loop work. The seven tools wrap a Unix socket exposed by the Tauri tauri-plugin-mcp Rust plugin (compiled into the signed app via the dev-mcp-plugin Cargo feature). They give an external Claude session direct control over the installed prod app:

• o8_view_screenshot— capture the current window as PNG base64. Always works, runs Rust-side.
• o8_view_snapshot— numbered accessibility tree for element discovery. Clicks reference these refs.
• o8_view_click / o8_view_type— interact with the running UI. Same gestures Playwright would use.
• o8_view_read— visible text of the page, for assertions.
• o8_view_eval— arbitrary JavaScript against the webview. Useful for inspecting state.
• o8_view_navigate / o8_view_wait_for— route changes and polling.

The day-to-day consequence: every code change in cortex-ide is verified through the same MCP loop you, as a third-party agent author, would use to drive o8. The development surface is the public surface. There is no special path inside.

We dogfood our own platform every commit. If the MCP surface regresses, our development loop breaks before any user's does.

MCP clients inherit the gates. They don't go around them.

A reasonable concern when you expose a fleet via MCP: doesn't this just turn the protocol into a backdoor around the governance you spent Note 03 explaining? No. The MCP server calls the same internal APIs the desktop UI calls. Those APIs are gated by the loopback + bearer-token middleware described in Note 03. The five trust gates (packet contract, worktree isolation, orchestrator review, operator approval, audit trace) all run regardless of which client initiated the dispatch.

• A third-party agent calling dispatch_mission still produces a packet that gets reviewed at G3 by the orchestrator before it reaches the operator inbox.
• A third-party agent calling o8_approvestill logs an event row in the approvals table with the client's identifier — we know which agent approved, not just “the operator approved.”
• A third-party agent calling cortex.askgets back cited facts — the same retrieval pipeline, the same source-of-truth hierarchy — with no privileged access to anything the operator wouldn't see.

The protocol is the surface. The governance is the substrate underneath. Adding an MCP client is the same security posture as adding a new device to the operator's network: it can do what the protocol allows, no more.

If MCP is the platform, the long-term position is “run any agent through us.”

The shipping product today is local-first, single-operator, single-machine. That's the right wedge for a power user managing their own fleet. The MCP-first architecture is what lets that wedge expand without rewriting the core.

• Hosted o8.When we ship a hosted multi- tenant tier (issue #967), the MCP server runs on our infra instead of the user's machine. Same toolset, same gates, same audit spine. A team using Claude Desktop can connect to a hosted o8 server and inherit the team's shared substrate without any client change.
• Cloud workers.A cloud worker adapter (issue #514) is a worker runtime that runs on a remote VM. The orchestrator talks to it through the same dispatch interface. From the MCP client's point of view, there is no difference between a local Codex worker and a remote cloud worker — both come back through the same review pane.
• Custom integrations.A team can write a custom MCP client that fits their existing workflow — Slack, Linear, Jira — and connect it to o8 the same way Claude Desktop does. We don't need to ship every integration ourselves.
• Multi-org substrate.The Brain is single-repo today. The MCP path is what lets a hosted tier expose a multi-tenant Brain — each tenant's substrate isolated, queryable through the same cortex.ask interface, with the protocol handling auth.

None of those require changing the core. They're additions on the spokes of the hub figure above. The hub itself stays the same shape.

Other tools picked the IDE-first model. Here's where the bets diverge.

We're not arguing that MCP is the only right protocol. We're arguing that picking any protocol that already has multi-vendor adoption and building everything on top of it is more durable than picking a custom shape and hoping the ecosystem follows. The bet is on standards compounding faster than custom tooling can catch up.

Editors lock you in. Platforms make the rest of the ecosystem land on top of you.

An editor-grade product is a place users go to do work. It competes with every other editor for the user's time. When a better editor ships, users move. When the model the editor wraps gets a competitor, users move.

A platform is a place where other toolsmeet to do work. The user's loyalty isn't to the platform — it's to the workflow the platform enables across the tools they already use. When a new model ships, the platform adds an adapter. When a new client surface ships, the platform exposes the same toolset to it. The user never has to migrate. The platform absorbs the change.

The editor-grade products will keep being good editors. We'll keep being the place where the agents they spawn end up coordinating — with each other, with the operator, with the substrate — through one protocol and one governance layer. That's the long position.

We don't want to win the editor fight. We want to be the control plane that the editors plug into.