The MCP server exposes 1DesignTool to external agents — connect any MCP-aware client (Claude Code, another coding agent, an automation) and it can drive the studio programmatically: create projects, send runs, read results. It's the studio's API surface, in the Model Context Protocol.
What MCP exposes
The server surfaces the studio's operations as MCP tools — the commands a connected agent can call:
- Project operations — create, open, list and drive projects
- Run operations — send briefs, read transcripts, drive turns
- Studio operations — read the state, the agents, the systems
A connected agent sees the same studio you do — the projects, the agents, the systems — and drives it through the protocol, not a side channel.
The access panel
Settings → MCP access shows the server's state: the endpoint it listens on, the clients allowed to connect, and the token the connection uses. It's where the access actually lives — the server is local, and the panel controls who can reach it.
By default the server is local-only — the panel gates which clients may connect, and the activity log records what each one does.
Connecting a client
Point an MCP-aware client at the studio's endpoint with the token from the access panel — the connection registers in the panel, and the client's tools expose the studio's commands. From there the client drives the same operations you click: create a project, send a run, read the result.
Reveal a token again
Each connection's token is kept in the app's data, readable only by your user account. When you need to wire a second client or rebuild a config, Reveal token on the connection's row in Settings → MCP access shows the token and its setup snippet again, and every reveal is logged. Connections created before 1.15.0 were made before tokens were kept, so their button is disabled until you Rotate them once. Revoke ends a connection for good.
The app doesn't have to be open
Since 1.15.0 a connected client can reach the studio even when you have closed it. If 1DesignTool isn't running, the client starts it in the background, with no window and no Dock icon. That background copy quits after 15 idle minutes, becomes a normal session if you open the app yourself, and stops when external access is turned off in the panel.
Watch an MCP turn land
A connected client doesn't get a side channel — its turns arrive like yours. Here Cursor sends a re-design to a mobile-app project that the studio built a turn earlier: the prompt carries a via MCP · Cursor tag instead of a composer send, the run plays out in the transcript, and the gate reports when it finishes.
The project history keeps the provenance too — an MCP turn counts toward the project's MCP turn total and the connection shows in its access row, so a design driven from outside is always attributable.
Automation through MCP
Because the server is the studio's real API, automation is a natural fit — a nightly script that regenerates the design tokens, a CI step that rebuilds the brand board, an external agent that runs the studio's loop itself. The activity log under Settings → MCP shows what each connected client did — the calls, the runs, the results.
Local-first, same as everything else
The MCP server runs on your machine — the endpoint is localhost, the token is yours, the calls stay local. An MCP client drives your studio the same way you do: through your agent CLIs, your quota, your files.
Tip: Open the access panel before wiring a client — the token and the allowed-client list are there, and a refused connection usually means the client wasn't on the list, not that the server's down.