@oneredesign/mcp-designer

Thin-client MCP server: lets a customer's local Claude Code drive their own OneRedesign designs against the deployed app, authenticated by a per-user API token. No Supabase SDK, no service_role, no direct DB access here — the mcp-designer edge function (apps/web/supabase/functions/mcp-designer) enforces "only your own designs" via RLS on a real impersonated session; see that function's own header comment for how.

Published, but unlinked

This package is public on npm (npm publish --access public), so npx @oneredesign/mcp-designer works from any machine with Node — but nothing in the product links to it (no marketing, no /docs, no account UI, no llms.txt/content.ts). Existence on the registry is the only thing that's public; discovery is still fully manual until the account-page "Connect your editor" flow ships.

Register in Claude Code

claude mcp add oneredesign -e ONEREDESIGN_TOKEN=<your token> -- npx -y @oneredesign/mcp-designer@latest

Always pin @latest, not a bare npx -y @oneredesign/mcp-designer — npx's own cache means a bare install can silently keep running whatever version first got cached on that machine instead of picking up a new one. @latest makes a reconnect always pull current.

Get a token from the operator (token-admin edge function mints one from a user id — no self-serve UI yet).

ONEREDESIGN_API_URL overrides the backend base URL (defaults to prod) — useful for pointing this package at a local supabase functions serve during development.

Tools

describe_capabilities, list_designs, get_design({ id?, screenId?, compact? }), create_design({ name?, devicePreset? }), rename_design({ id, name }), delete_design({ id, confirm }), upload_asset({ id, dataUrl }), upload_font({ id, name, dataUrl }), apply_ops({ id?, ops, validateOnly? }), render_screen({ id?, screenId, scale? }). ops is the same design_ops schema as the in-app AI designer (supabase/functions/design-chat/designOps.ts), plus reorderScreens. Edits are headless — reload the canvas to see a change.

describe_capabilities's response includes apiVersion (bumped only when the op ENVELOPE changes — a new required top-level key, a changed field meaning) plus supportedOps/supportedTools, so an agent can tell what the currently-connected backend actually supports without needing a client update to find out.

Update story for customers

New node fields (a text-stroke property, a new gradient type, etc.) need zero client update — apply_ops's node/patch objects pass unrecognized fields through as-is (opsSchema.ts's zod schemas are .passthrough(), not .strict()); the deployed backend (validateOps.ts/applyOps.ts) is the real, independently-deployed gate. Likewise a new device preset name works immediately (devicePreset is z.string(), not a hardcoded enum). Only a genuinely new op type or tool needs a client version bump — and even then, @latest in the registration command means a customer picks it up on their next reconnect with no action required.

Publishing a new version

cd apps/web/tools/mcp-designer-remote
npm run build
npm version <patch|minor|major>
npm publish --access public   # needs an npm auth token with oneredesign org access, e.g. supabase/.env's NPM_TOKEN

Dev

npm run typecheck
ONEREDESIGN_TOKEN=... ONEREDESIGN_API_URL=http://127.0.0.1:55321/functions/v1/mcp-designer npm start