Drive 1DesignTool from any agent (MCP)

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.

The MCP access panel — endpoint, allowed clients, the connection token

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.

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.

A turn dispatched over MCP — the prompt bubble carries the client's name
The MCP-dispatched re-design complete — gate passed, files updated
A mobile app built in-app, then re-designed by an MCP client.

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.