10.1 What MCP Is

MCP (Model Context Protocol) is an open standard that lets an AI agent connect to external tools and data sources. Think of it as a USB-C spec for AI: the same socket, regardless of which device you plug in. Open Design is the device; your coding-agent CLI is the charger.

The protocol uses JSON-RPC 2.0 for message transport. A host (the application, Open Design in this case) runs a server; a client (the agent CLI) connects and issues requests; the server responds with structured data. The three layers are fixed by the spec:

MCP was created by Anthropic and, per the governance announcement in December 2025, donated to the Agentic AI Foundation (under the Linux Foundation). The spec is published at modelcontextprotocol.io under open governance; the governance announcement describes the intent that any vendor may implement it. (This book describes that governance structure as documented — it is not legal advice on IP ownership or licensing freedom; consult qualified counsel for those determinations.) At this book's June 2026 edition, the stable spec version was 2025-11-25, with a 2026-07-28 revision in release candidate; check the spec page for current status.

The standard defines three primitives that any MCP server can expose to connected clients. Open Design implements all three. Here is what they mean in context:

The governance story matters to designers as much as it matters to engineers. MCP is a standard, not a product. When you connect Open Design via MCP, you are not depending on a proprietary plug-in that any one vendor can revoke. One server, many brains — and that relationship is defined by an open spec, not a proprietary API key.

10.2 Open Design's MCP Server

Open Design's daemon runs an MCP server alongside its Express HTTP layer. The MCP server listens for agent connections, authenticates them, and routes their requests to the daemon's generation, file, and project subsystems. You do not start it separately; it starts with the daemon.

As of v0.9.0 (released June 2, 2026), the MCP server gained three new tools: write_file, delete_file, and delete_project, and resolved a long-standing limitation around project directory exposure. The release notes call this "MCP clients can now do real workspace work" — enabling agents to edit and manage files programmatically alongside reading.

One server, many brains: a single daemon instance runs the MCP server; each connected agent is a separate client session against the same server. You can have Claude Code, Cursor, and OpenCode all connected simultaneously, each working on a different project or variation in the same Open Design instance.

10.3 Connecting an Agent

The od mcp install <agent> command writes the MCP configuration to the CLI's expected config directory, registers the Open Design daemon as a connected server, and optionally injects the active skill context. As of v0.21.1, every supported agent has its own adapter with its own config format — the install command abstracts that difference.

$ od status
daemon: running (v0.9.0)
mcp-server: listening
projects: 3

$ od mcp install claude-code

$ od mcp install claude-code --print

$ od mcp install cursor
$ od mcp install opencode
$ od mcp install codex

$ od mcp install cursor --uninstall

Per-CLI config formats differ. Claude Code uses its native .claude/ config directory with a first-class MCP section. Cursor Agent writes to .cursorrules. Codex uses its own config directory and has known version-specific variance. The od mcp install command handles all of these; you do not need to know which format each agent expects.

The Settings → OpenDesign MCP page (v0.21.1)

Since the 0.19-era updates, first-party setup has moved into Workspace settings under an OpenDesign MCP section --- "Connect OpenDesign to your coding agent." The page states what an agent can actually do once connected: read or search any file in a project; collect a design's files, styles, components, and fonts as context; and use the project and file currently open in OpenDesign as context. That is the honest scope of the integration --- project work, not whole-machine access.

Each agent gets a copy-paste setup command rather than a hand-edited config. For Claude Code it is an add-json call that registers the server with the daemon's paths (the ellipses are the install-specific values the page fills in for you):

$ claude mcp add-json --scope user open-design '{
  "command": "…",
  "args": ["…"],
  "env": {
    "OD_DATA_DIR": "…",
    "OD_SIDECAR_IPC_PATH": "/tmp/open-design/ipc/release-stable/daemon.sock",
    "OD_MCP_BOOTSTRAP_COMMAND": "/usr/bin/open"
  }
}'

The page closes with the two instructions people skip: keep OpenDesign running --- the MCP server lives in the daemon, so quitting the app disconnects every agent --- and restart your coding agent after setup so it picks up the new server. For Claude Desktop there is no JSON at all: od mcp install claude-desktop (0.19.1) configures the connection on macOS and Windows.

10.4 Resources, Tools, and Prompts

Once connected, the agent can see everything the MCP server exposes. This is the full surface area of Open Design as seen by a connected agent — not a UI, but a structured protocol surface the agent can query and call.

The v0.9.0 addition of write_file and delete_file is more significant than it sounds. Before that release, MCP clients could drive generation but could not do independent file work inside the project workspace. Now a connected agent can fetch an artifact, rewrite a specific file within it, and clean up intermediate files — all without leaving the agent session or switching to the Open Design UI.

10.5 The BYOK Proxy

Open Design does not bundle an inference provider. You bring your own key (BYOK), configure a provider, and the daemon proxy routes calls to the model on your behalf. The proxy endpoint pattern is:

POST /api/proxy/{provider}/stream

# Where {provider} is one of:
# anthropic | openai | azure | google | ollama | senseaudio

Each route accepts a baseUrl, apiKey, and model in the request body. The proxy supports Anthropic, OpenAI, Azure OpenAI, Google Gemini, Ollama, LM Studio, vLLM, and any OpenAI-compatible endpoint. Per the Open Design v0.9.0 security documentation, your key is stored in config.toml with mode 0600, designed to be accessible only by the daemon process owner.

The local-first vs local-inference distinction reappears here. Open Design is local-first: your files, your project workspace, and the daemon orchestration all run on your machine. But inference is local only when you choose the ollama provider. Every other provider sends the generation request to a cloud model. If inference privacy is your goal, configure Ollama and a local model before connecting an agent.