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.) As of June 2026, the stable spec version is 2025-11-25; a 2026-07-28 revision is in release candidate.

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 June 2026, 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.

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.

10.6 Supported CLIs

As of Open Design v0.9.0 (released June 2, 2026), the daemon ships adapters for a growing list of coding-agent CLIs. The v0.9.0 release added Aider, Trae CLI, and DeepSeek Reasonix — three new agents that reflect how fast this market is expanding. New entries appear in each minor release; this table reflects the snapshot at publication.

The remaining adapters (Pi Agent, Mistral Vibe CLI, Hermes, Qwen, Qoder, Kiro, Kilo, OpenClaw, VS Code + Copilot, and others added in subsequent releases) follow the same install pattern with their respective IDs. All listed adapters support MCP; what differs is the config format each CLI expects and how Open Design's adapter bridges the gap.

A note on Gemini CLI: as of June 2026, per Open Design's adapter documentation, the Gemini CLI adapter is classified P2 and treated as sunset in Open Design's priority scheme. The gemini adapter remains in the codebase for users on older configurations, but do not start a new project with it. Verify the current sunset status and timeline directly with Google before publication. The Google Antigravity adapter is the current Google-family successor in Open Design's adapter list.

Chapter 11 compares the headline agents in depth — use the comparison there to choose which CLIs to actually invest in. This chapter's job is to confirm that the connection is the same for all of them and that swapping agents is a one-command operation.

10.7 Integrations beyond MCP: Connectors and Skills

MCP connects agents to Open Design. Connectors connect Open Design to external data. The Integrations surface --- reachable from the sidebar and the home header's Use everywhere link --- documents CLI, MCP, HTTP, and headless paths alongside connector and skill management. As of v0.15.1 the sidebar groups these as Connectors (external services) and the in-page tabs expose Composio-backed connector setup plus a Skills manager for installed recipes.

The Connectors tab is backed by Composio --- a connector runtime that abstracts OAuth and API-key management for hundreds of external services. Paste a Composio API key at the top of the tab; the key is stored locally and never transmitted to Open Design's servers. Once configured, a searchable grid of service tiles appears. Activating a connector makes its data surface available to any Live artifact you generate: a dashboard wired to Notion, Airtable, or Slack reads live data instead of placeholders. That is what separates a live artifact from a prototype.

The Skills manager on the same Integrations surface lists installed recipes, discovery paths, and headless invocation entry points. It complements the skill-authoring model in Chapter 04: skills define generation structure; the manager shows which recipes are active in your environment and how to invoke them outside the Electron window.