claude-design-mcp

Talk to Claude Design from Claude Code. Send it design instructions, read what it says back, pull the files it makes into your repo, and put the right screen on your display so you can watch it work.

Claude Design is a separate product from Claude Code. It has its own projects, its own chats, and its own files, and no API. So the two never met.

This is the bridge. Claude Code can now ask the designer for a screen, watch it being drawn, read the reasoning, and pull the result straight into the codebase.

you  →  Claude Code  →  claude.ai/design  →  a design
                     ←  its reply, its files  ←

Install

/plugin marketplace add marvin-socialista/claude-design-mcp
/plugin install claude-design@claude-design

Then once, in the installed plugin directory:

npm install     # Playwright and the MCP SDK
npm run seed    # copy your claude.ai session into the tool's browser profile
npm run smoke   # read-only check, spends nothing

npm install is not optional and not automatic: this drives a real browser, so Playwright has to be there.

seed copies only claude.ai cookies out of a Chrome profile you already use (~/.claude/playwright-profile by default, or pass another path). Nothing else from that profile is read or duplicated. If it is not signed in, or the session later expires, npm run login opens a window so you can sign in by hand.

git clone https://github.com/marvin-socialista/claude-design-mcp
cd claude-design-mcp && npm install && npm run seed
claude mcp add claude-design --scope user -- node "$PWD/src/index.mjs"

Related MCP server: Herald

Tools

Start something

Talk to it

See and read what it built

Move work around

Delete (permanent, no trash, no undo)

delete_project is guarded the way GitHub guards repo deletion. A UUID is easy for an agent to carry over from the wrong step; a name has to be looked up and matched deliberately. Verified: it refuses "Bridge test DS" when the project is actually called "Bridge test DS (safe to delete)".

The plugin also ships a claude-design skill that teaches Claude when and how to reach for these, so you can just say what you want.

Attaching a local folder, without a native file dialog

"Link local code" has no file input. Its browse… calls window.showDirectoryPicker(), a native OS dialog that no automation can drive, which normally ends the story.

So the picker is replaced. link_local_code reads the folder in Node, then injects a synthetic FileSystemDirectoryHandle implementing the parts the app uses (values, entries, getFileHandle, getDirectoryHandle, queryPermission) and overrides showDirectoryPicker to return it. The handle is given the real prototype via Object.setPrototypeOf, so an instanceof check still passes while our own methods shadow the native ones, which would throw on a foreign object.

Verified end to end: after attaching src/, Claude Design listed all five files and quoted the first line of session.mjs correctly.

Text files only, skipping .git, node_modules and build output, bounded by file count and total bytes. Point it at a frontend or design-system folder rather than a monorepo.

The handle is synthetic and lives in the page. A real one is persisted and re-permissioned across sessions; this one is not, so re-attach if a later session needs the files again.

Seeing the work, not just hearing about it

screenshot returns the rendered page as an image, so Claude Code can judge layout, spacing, type and colour instead of trusting the reply text. Use width: 402 for an iPhone-class frame, format: "png" to read fine type, and fullPage: true with savePath for a long document.

search_code plus read_file covers the other half: read the markup Claude Design actually wrote, without pulling anything to disk. A .dc.html page runs to hundreds of KB, so grep first, then read the region.

Watching it work

The browser sits parked offscreen while data is read, so nothing interrupts you. open_screen moves it onto the display over CDP rather than relaunching, and send_prompt defaults to visible: true.

Open the screen the work is about before sending the prompt, so you watch it change instead of being shown the result afterwards. Page names in the switcher drop the extension: ask for Prototype.dc.html and it matches the page listed as "Prototype".

How it works

There is no public API. What follows was worked out by reading the app's own network traffic and shipped bundle.

claude.ai/design speaks a Connect-RPC service, anthropic.omelette.api.v1alpha.OmeletteService. Plain cookie auth, no extra headers. The useful methods:

Reads go over the RPC. Sending a prompt goes through the real page. That split is the whole design, and it is not laziness.

Chat does not take a prompt string. It takes messagesRequest, a bytes field holding the entire model request the client assembles, and it streams tool_delta / tool_block_complete events back. The browser executes those tools. The bundle contains the client-side executor (case 'local_read': …) for roughly twenty of them: reading and writing project files, grep, screenshots, check_design_system, generate_image, the Figma bridge. The agent loop lives in the page.

Calling Chat directly would therefore mean reimplementing Claude Design's harness: its system prompt, every tool schema, every tool implementation, and the turn lifecycle (CancelChat, ReleaseTurn, the park-and-wake path). That is cloning the app. Driving the page instead gets all of it for free, and costs one Chrome process.

Knowing when it has finished

Two signals, both required.

Network quiet is tracked with a PerformanceObserver on resource timings, which is how the app itself watches its own stream: entries are reported on completion, so a new …/Chat entry means a stream just ended. One user turn is several streams (model asks for a tool, browser runs it, next stream carries the result), so quiet means "no stream has ended for idleSeconds".

Quiet alone is a trap, though. A long tool call is silent, so a turn in flight can look finished. The decisive signal is an assistant message with content actually landing in the transcript. Only when both hold does send_prompt return.

No fetch patching anywhere, so nothing here can break the page.

Why the browser is visible

Chrome runs headed but parked offscreen at -2400,-2400. This is not cosmetic: Cloudflare serves headless Chrome a 403 challenge on claude.ai even with a valid session and stealth evasions loaded. Verified both ways, headless 403 and headed 200.

Limits worth knowing

• This rides an internal, undocumented API. It can change without notice and there is no support if it does.

• It spends your normal Claude credits and is subject to the usual rate limits.

• Do not close the browser mid-turn. The browser is the agent's tool executor, so killing it aborts the work in progress and no reply is saved.

• send_prompt posts into the project's active chat. Pass chatId to aim it, which clicks through the chat-history popover, since no URL selects a chat (?chat=, /c/<id> and /chat/<id> all load the project and leave the previous thread selected). Creating a new chat is not automated.

• File entries carry no version or mtime, so send_prompt reports files added and removed accurately but cannot see an in-place edit. The reply text is what tells you those.

• The page switcher lists pages, not every file. Use pull_files for the rest.

• HTML comes back with Claude Design's own preview runtime bolted to the front, a data-omelette-injected style and script pair worth about 15 KB. read_file strips it; pass raw: true to keep it.

• WriteFiles takes mutations with a write oneof, and its data is a plain string, not proto bytes. Both mistakes fail silently, returning 200 while storing an empty file or the literal base64. write_files therefore reads back what it wrote and raises if nothing landed.

Support

If this saved you time, you can buy me a coffee ☕.

License

MIT