penpot-mcp

# penpot-headless A portable MCP server for headless Penpot project/file/content management, using Penpot's RPC API directly. No browser, no Penpot plugin session. This package has **zero project-specific knowledge** — no hardcoded colors, fonts, or Penpot instance URL. Every consuming project supplies its own config and token file, so it can be installed from npm or copied as-is into another project. ## What this does - Team/project/file/page CRUD (`penpot_list_teams`, `penpot_create_file`, etc.) - Shape creation — `rect`, `frame`, `text`, `circle` (ellipse), `path`, `bool` (boolean operations), and `image` — via `penpot_add_shapes`, with colors/fonts resolved either from a literal value or a `{ "token": "name" }` reference against your project's token file. The same token-or-literal pattern applies to spacing (layout gaps/padding, layoutItem margins/min/max sizes), corner radii (`r1`-`r4`), and shadows (`shadows`, either an inline `{ style, color, offsetX, offsetY, blur, spread, opacity }` object or `{ "token": "name" }`). Shapes may be rotated via an optional `rotation` field (degrees, clockwise, about the shape's center). - Shape editing: `penpot_update_shapes` changes an existing shape in place by id — position, size, rotation, name, fill, stroke, shadows, corner radii, or (for text) content/font. Only the fields you pass are touched; everything else (children, component/variant tags, layout) is left as-is. `clearStroke`/`clearShadows` remove strokes/shadows entirely. Geometry changes automatically recompute the shape's selection box and transform, so a partial edit (e.g. just `width`) can't desync from the rest of the shape's geometry. Layout/layoutItem aren't editable this way — only settable at creation time via `penpot_add_shapes`. - Shape deletion: `penpot_delete_shapes` removes one or more existing shapes from a page by id. Deleting a frame or group also removes its children, matching Penpot's own delete behavior. - Shape grouping: `penpot_group_shapes` wraps one or more sibling shapes into a new group (Ctrl+G equivalent) — all shapes must share the same parent. The group is inserted at the topmost selected shape's z-order position and its bounding box is computed from the children's rotation-aware `selrect`s. `penpot_ungroup_shapes` dissolves a group (Ctrl+Shift+G equivalent): children are reparented to the group's former parent at the group's z-order slot, then the group is deleted. - Shape duplication: `penpot_clone_shapes` duplicates one or more existing shapes (and, for frames/groups, their full descendant subtree), each with fresh ids — plain shape duplication, like Penpot's own Ctrl+D, not a component instance. Optional `dx`/`dy` offset each clone from its source (defaults to no offset, stacked directly on top of the original); optional `parentId`/`frameId` reparent every cloned root instead of leaving it alongside its source. - Shape stacking order: `penpot_reorder_shapes` changes a shape's z-order among its siblings, matching Penpot's own "Bring to front" / "Send to back" / "Forward" / "Backward" UI actions. `action` is `front`/`back` (top/bottom of the stack), `forward`/`backward` (swap with the next/ previous sibling — a no-op if already at that end), or `before`/`after` (place immediately relative to another sibling given as `targetId`). Only reorders among existing siblings — it doesn't reparent. - Align & distribute: `penpot_align_shapes` lines up two or more shapes on a common edge or center (`left`/`right`/`top`/`bottom`/`center-h`/`center-v`), and `penpot_distribute_shapes` spreads three or more shapes so the gaps between them are equal (`horizontal`/`vertical`) — matching Penpot's own one-click align/distribute actions, instead of the agent computing pixel positions itself. Both work on each shape's visible bounding box (its `selrect`), so rotated shapes line up by their rendered bounds; align never moves the group as a whole, and distribute leaves the two outermost shapes fixed. Aligning or distributing a frame/group carries its whole child subtree along by the same offset. - Batched edits: `penpot_batch` applies an ordered list of create/update/ delete/reorder operations as a single `update-file` change-set — one `revn`/`vern` round trip no matter how many shapes are touched, instead of one RPC call per shape (and the races on `revn` that come with that). Each op takes the same fields as the matching standalone tool (`penpot_add_shapes` for `create`, `penpot_update_shapes` for `update`, etc.); a `create` op may set an explicit `id` and be referenced as a later op's `parentId`/`frameId` or targeted by a later `update`/`delete`/`reorder` in the same call, so a whole form or card grid can be built in one round trip. - Undo point: `penpot_checkpoint` snapshots shapes and returns a `checkpointId`; `penpot_restore_checkpoint` undoes everything since — including a wrong `penpot_delete_shapes` call, which otherwise has no undo path short of Penpot's own UI. Supply `pageId` to scope the snapshot to a single page; omit `pageId` for a whole-file checkpoint that covers every page. Works by diffing current state against the snapshot and replaying corrective changes as a single `update-file` call (recreate what's missing, delete what's new, overwrite what changed back to its snapshotted fields), since Penpot's RPC has no "revert to revn X" primitive. Checkpoints live in the MCP server's memory (not the Penpot file, not disk) and are reusable — restore to the same point as many times as you like — until explicitly freed via `penpot_discard_checkpoint` or the server process restarts. - Shape lookup: `penpot_get_shape` fetches a single shape by id, without pulling the whole page via `penpot_get_file_snapshot`. By default nests the shape's full descendant subtree under `shapes`; `includeDescendants` and `maxDepth` control how much of the subtree comes back. Always includes a `componentInfo` field: `linkState` (`"linked"` / `"detached"` / `"not-an-instance"` / `"main-component-root"`), and — for same-file linked instances — a `driftedFields` array listing the camelCase field names that differ from the main component's current definition (empty = fully in sync). - Shape search: `penpot_find_shapes` searches every shape on a page against one or more predicates — `type`, `name` (exact match), `nameContains` (case-insensitive substring), `textContains` (case-insensitive substring against a text shape's rendered characters), `isComponentInstance`, and/or `isRoot` — all given filters must match (AND). Omit every filter to list the whole page. Returns each match's id/type/name/position/size plus `linkState` and (for linked same-file instances) `driftedFields`; use `penpot_get_shape` on a match's id for the full subtree and detailed `componentInfo`, optionally capped via `limit`. - Text measurement: `penpot_measure_text` computes the real rendered width/height of a string for a given font (family/size/weight), without creating or touching any shape — removing the guesswork around `width`/ `height` when calling `penpot_add_shapes`/`penpot_update_shapes` for text. Tries Google Fonts first (by family name, no API key needed); if the family isn't there, searches all Penpot teams accessible to the configured token for a matching custom/team font, so fonts uploaded directly to your Penpot instance are also measurable. Measures real glyph advance widths (plus kerning) so the numbers match what Penpot renders. Splits on explicit `\n`; pass `maxWidth` to also get word-wrapped line breaks for a fixed-width box. - Auto-layout: a `frame` may declare flex or grid layout via an optional `layout` field (direction, gap, padding, alignment; grid also takes row/column track definitions). Any shape may set `layoutItem` to control its own placement within an auto-layout parent (sizing, alignment, margins, min/max size, and — for grid parents — row/column/span). - Components: `penpot_create_component` registers a shape tree (same specs as `penpot_add_shapes`) as a component's main instance; give shapes explicit `id`s to nest them, and the one shape not parented to a sibling becomes the root. `penpot_add_component_instance` then places a full copy of that tree elsewhere on a page, linked back to the main instance via Penpot's `shape-ref` so it's recognized as a proper component copy — reusable any number of times. - Variants: `penpot_create_variant_group` groups two or more components (built the same way as `penpot_create_component`, one per variant) into a single container tagged with shared property axes (e.g. a "Button" with Type=Primary/Secondary). This wires up Penpot's actual variant-swap system — confirmed live via the Penpot plugin API, including `instance.switchVariant(pos, value)` correctly swapping a placed instance between variants. `penpot_add_variant` adds a new variant to an already-existing variant group container: accepts the same shape specs as one entry in `penpot_create_variant_group`'s `variants` array and the `containerId` returned by that tool (or found via `penpot_find_shapes`), then appends the new variant's main instance to the container's `shapes` array and registers a new component — all in a single `update-file` call. - `penpot_list_components` enumerates a file's existing components (from its `data.components` map), instead of requiring the caller to have created them itself in the same session or parse `penpot_get_file_snapshot`'s output by hand. Each entry includes the `componentId` (usable with `penpot_add_component_instance`), `name`, `mainInstanceId`/ `mainInstancePage`, and — for variant components — `variantId`/ `variantProperties`. - Media upload: `penpot_upload_media` uploads an image or other asset to a Penpot file and returns the media object metadata (`id`, `width`, `height`, `mtype`). Accepts a local file path (`filePath`), a remote URL (`url` — Penpot's server fetches it directly), or base64-encoded bytes (`dataBase64` + `mtype`). The returned `id` is used as `mediaId` when creating an `image` shape. - Comments: `penpot_list_comment_threads` lists all threads for a file; `penpot_get_comments` fetches replies inside a thread; `penpot_create_comment_thread` pins a new thread to a canvas position (x/y, optional `frameId`); `penpot_create_comment` adds a reply; `penpot_update_comment` edits a comment's text; `penpot_resolve_comment_thread` marks a thread resolved or reopens it; `penpot_delete_comment` removes a single reply; `penpot_delete_comment_thread` removes a whole thread. - Version history: `penpot_list_file_snapshots` lists all named snapshots for a file; `penpot_create_file_snapshot` saves the current state as a named version (equivalent to "Save version" in the Penpot UI, with an optional `label`); `penpot_restore_file_snapshot` rolls the live file back to a snapshot (Penpot automatically saves a system backup before restoring, so restores are themselves undoable); `penpot_rename_file_snapshot` / `penpot_delete_file_snapshot` manage user-created versions; `penpot_lock_file_snapshot` / `penpot_unlock_file_snapshot` protect a version from accidental deletion; `penpot_get_file_snapshot_data` returns the full file content at a snapshot for read-only inspection. - Reading a file's current shape tree via `penpot_get_file_snapshot`. - Rendering shapes or pages to PNG/SVG/PDF via `penpot_export_shape` (single shape) and `penpot_export_batch` (multiple shapes in one call, returned in the same order, across any number of pages — use the `shapes` array for multi-page exports; the `shapeIds` shorthand is still available when all shapes share the same page) — requires `PENPOT_LOGIN_EMAIL`/`PENPOT_LOGIN_PASSWORD`, `PENPOT_OIDC_USERNAME`/`PENPOT_OIDC_PASSWORD`, or `PENPOT_AUTH_TOKEN_COOKIE`, see below — no browser tab or Penpot plugin session needed on your end. ## Render/export capability `penpot_export_shape` renders a single shape (or an entire page, by passing its root frame's id) to PNG, SVG, or PDF, using Penpot's own server-side exporter — the same headless-Chromium-backed service Penpot's self-hosted stack already runs (the `penpotapp/exporter` container). `penpot_export_batch` accepts either a `shapeIds` array (all shapes on the same `pageId`) or a `shapes` array where each entry can specify its own `pageId`, `format`, `scale`, and `name` — enabling whole-file exports across multiple pages in a single API call. All formats (PNG/SVG/PDF) are supported. No browser automation happens in this package; it's two HTTP calls (auth, then export) against your Penpot instance. This needs a **second, separate auth mode** from the rest of this package: Penpot's export pipeline (`POST /api/export`) is a distinct microservice from the `/api/rpc/command/*` surface everything else here uses, and it authenticates purely via a session cookie — a personal access token in an `Authorization` header is never read on this path (confirmed by reading Penpot's exporter source: its `wrap-auth` looks for a literal `auth-token` cookie and nothing else), independently of `PENPOT_ACCESS_TOKEN`. Three ways to supply this cookie — configure exactly one: **Option A — password login** (`PENPOT_LOGIN_EMAIL` + `PENPOT_LOGIN_PASSWORD`): The server logs in with email/password to obtain the `auth-token` cookie and caches it for the process lifetime, re-logging-in automatically on expiry. Best for instances that expose password login. `PENPOT_ACCESS_TOKEN` and these credentials must belong to **the same Penpot account** (or at least accounts with access to the same team); mismatched accounts cause a silent 10-second render timeout because the exporter can't distinguish "access denied" from "shape not visible." **Option B — headless OIDC/SSO login** (`PENPOT_OIDC_USERNAME` + `PENPOT_OIDC_PASSWORD`): The server drives the OIDC redirect flow over plain HTTP: it follows Penpot's OAuth endpoint redirect chain to the identity provider's login page, parses the HTML login form, submits the credentials, and captures the resulting `auth-token` cookie — no browser or external tooling needed. Re-logs in automatically on expiry. Works for form-based IdPs that render a standard HTML login form (Keycloak, Authentik, Dex, and similar). Does **not** work for JavaScript-driven login pages (Google, Microsoft, Okta hosted login) because their login UIs are SPA shells with no server-rendered form. Set `PENPOT_OIDC_PROVIDER` to the OAuth provider name configured on your Penpot instance (default: `"oidc"`). Most self-hosted setups use this default; check your Penpot server flags if login doesn't start. **Option C — pre-obtained SSO/OIDC cookie** (`PENPOT_AUTH_TOKEN_COOKIE`): Paste the raw value of the `auth-token` cookie from a browser session in which you already completed the OIDC/SSO login. The server uses it as-is and emits a clear error if it expires (since it has no credentials to re-login with). Works for instances where password login is disabled and the IdP uses a JavaScript-driven login page (where Option B can't reach). To obtain the cookie value: 1. Open your Penpot instance in a browser and complete the SSO/OIDC login. 2. Open DevTools → Application → Cookies → your Penpot domain. 3. Copy the value of the `auth-token` cookie (not the whole `Cookie:` header — just the token value after `auth-token=`). 4. Set `PENPOT_AUTH_TOKEN_COOKIE` to that value. If none of the options is configured, `penpot_export_shape` is not registered and every other tool works exactly as before. ## Setup 1. Generate a Penpot access token: your Penpot instance → Account settings → Access tokens. (Self-hosted instances: this section is hidden unless the backend/frontend are started with `PENPOT_FLAGS` including `enable-access-tokens`.) 2. Create a token file for your project (see `design-tokens/*.tokens.json` in the consuming repo for an example — or write your own matching the schema below). 3. If you want `penpot_export_shape`, also configure one of: - **Password login:** set `PENPOT_LOGIN_EMAIL`/`PENPOT_LOGIN_PASSWORD` to the **same account** the access token above belongs to. - **Headless OIDC login:** set `PENPOT_OIDC_USERNAME`/`PENPOT_OIDC_PASSWORD` to your IdP credentials. Works for form-based IdPs (Keycloak, Authentik, Dex). Set `PENPOT_OIDC_PROVIDER` if your provider name differs from the default `"oidc"`. - **SSO/OIDC cookie:** set `PENPOT_AUTH_TOKEN_COOKIE` to the raw `auth-token` cookie value from a browser session in which you completed the SSO login (see "Render/export capability" above). Use this for JavaScript-driven IdP login pages where headless OIDC can't reach. Skip this step entirely if you don't need rendering. 4. *(Optional)* To persist checkpoints across server restarts, set `PENPOT_CHECKPOINTS_PATH` to a local directory path. When set, each `penpot_checkpoint` call writes a JSON file to that directory; on startup the server reloads any files already there, so a checkpoint survives the MCP server being restarted mid-way through a long edit. The directory is created automatically. Without this setting, checkpoints live only in process memory (the previous behaviour). 5. Register this server in your MCP client config, e.g. (password-login variant): ```json { "mcpServers": { "penpot-headless": { "command": "npx", "args": ["-y", "@ai-dala/penpot-headless"], "env": { "PENPOT_BASE_URL": "https://your-penpot-instance.example.com", "PENPOT_ACCESS_TOKEN": "your-token-here", "PENPOT_TOKENS_PATH": "/path/to/your-project/design-tokens/tokens.json", "PENPOT_LOGIN_EMAIL": "same-account-as-the-token-above@example.com", "PENPOT_LOGIN_PASSWORD": "that-account's-password" } } } } ``` Or, for an SSO/OIDC-only instance with a form-based IdP (headless OIDC login): ```json { "mcpServers": { "penpot-headless": { "command": "npx", "args": ["-y", "@ai-dala/penpot-headless"], "env": { "PENPOT_BASE_URL": "https://your-penpot-instance.example.com", "PENPOT_ACCESS_TOKEN": "your-token-here", "PENPOT_TOKENS_PATH": "/path/to/your-project/design-tokens/tokens.json", "PENPOT_OIDC_USERNAME": "your-idp-username-or-email", "PENPOT_OIDC_PASSWORD": "your-idp-password" } } } } ``` Or, for an SSO/OIDC-only instance with a JavaScript-driven IdP login page: ```json { "mcpServers": { "penpot-headless": { "command": "npx", "args": ["-y", "@ai-dala/penpot-headless"], "env": { "PENPOT_BASE_URL": "https://your-penpot-instance.example.com", "PENPOT_ACCESS_TOKEN": "your-token-here", "PENPOT_TOKENS_PATH": "/path/to/your-project/design-tokens/tokens.json", "PENPOT_AUTH_TOKEN_COOKIE": "the-auth-token-cookie-value-from-your-browser" } } } } ``` Or, if working from a local clone instead of the published package: ```json { "mcpServers": { "penpot-headless": { "command": "npx", "args": ["tsx", "/path/to/penpot-mcp/src/server.ts"], "env": { "PENPOT_BASE_URL": "https://your-penpot-instance.example.com", "PENPOT_ACCESS_TOKEN": "your-token-here", "PENPOT_TOKENS_PATH": "/path/to/your-project/design-tokens/tokens.json", "PENPOT_LOGIN_EMAIL": "same-account-as-the-token-above@example.com", "PENPOT_LOGIN_PASSWORD": "that-account's-password" } } } } ``` ## Token file schema ```json { "colors": { "accent": "#7AA2FF", "bg-surface": "#111726" }, "fonts": { "sans": { "family": "Inter", "weights": ["400", "500", "600"] } }, "spacing": { "sm": 8, "md": 16, "lg": 24 }, "radii": { "sm": 4, "md": 8, "pill": 999 }, "shadows": { "card": { "style": "drop-shadow", "color": "#000000", "opacity": 0.3, "offsetX": 4, "offsetY": 4, "blur": 8, "spread": 2 } } } ``` All four token tables are optional except `colors`. Any color-typed field in `penpot_add_shapes`/`penpot_update_shapes` accepts either a literal hex string or `{ "token": "accent" }`, resolved against this file at call time. The same applies to: - **Numeric fields** (layout gaps/padding, layoutItem margins/min/max sizes, and corner radii `r1`-`r4`) — either a literal number or `{ "token": "sm" }`, resolved against `spacing` (gaps/padding/margins) or `radii` (corner radii). - **`shadows`** on a shape — an array where each entry is either an inline `{ style, color, opacity, offsetX, offsetY, blur, spread }` object (color itself may also be a `{ "token": "name" }` reference) or `{ "token": "card" }`, resolved against `shadows`. `style` is `"drop-shadow"` (default) or `"inner-shadow"`. ## Testing Two suites, split because they need very different things: - **Unit** (`npm test`) — pure functions in `shape-builders.ts` (rotation matrix math, layout attribute mapping, the camelCase-in/kebab-case-out shape extraction `penpot_update_shapes` relies on) and `font-metrics.ts` (line-splitting/word-wrap logic, measured against a hand-built fake font so no network call is needed). No network, no Penpot account, runs anywhere. This is the suite CI runs on every push/PR. - **Integration** (`npm run test:integration`) — exercises the actual MCP tool handlers against a real Penpot instance via `PENPOT_BASE_URL`/ `PENPOT_ACCESS_TOKEN` (reads `.env`, same as the server itself). Each test creates its own scratch project and deletes it in a `finally` block, even on failure — see `test/integration/helpers/scratch-project.ts`. Skips itself (doesn't fail) if credentials aren't configured. **Local/ manual only — deliberately not run in CI**, since it mutates a real Penpot account and CI credentials for that are out of scope for this project. Run it yourself before trusting a change to Penpot's wire schema (rotation, layout, components, variants). `font-metrics.test.ts` also lives in this suite despite not needing Penpot credentials — it makes a real call to the public Google Fonts CDN, which the unit suite's "no network" rule excludes; it skips itself if that network call fails rather than needing `PENPOT_ACCESS_TOKEN`. This split matters because Penpot's RPC schema accepting a change is not the same as Penpot's editor correctly rendering or recognizing it — the variant-id bug documented in `shape-builders.ts` (`variantContainerAttrs`) was only caught by live testing, not by the schema validating successfully. `npm run test:all` runs both. ## Copying to another project This package is published to npm as `@ai-dala/penpot-headless`, so most consuming projects can just reference it via `npx` (see above) without a local copy. If you'd rather vendor it, this directory has its own `package.json`/`tsconfig.json` and depends only on `@modelcontextprotocol/sdk`, `zod`, and `opentype.js` (used by `penpot_measure_text` to parse real font files) — no framework dependencies. Copy the whole `penpot-headless/` directory into the new project, run `npm install`, write a token file for that project, and register the server with a `PENPOT_TOKENS_PATH` pointing at it. ## Known limitations - `penpot_measure_text` doesn't apply ligature substitution (e.g. rendering "fi" as one glyph) — it sums individual glyph advances (with real GPOS kerning) instead of using opentype.js's built-in shaping, because that shaping path throws on GSUB tables present in most current-generation Google Fonts, including Inter and Roboto (see `measureLineWidth` in `font-metrics.ts`). This is a deliberate tradeoff, not an open gap: the width difference from skipping ligatures is a few percent at most for typical UI text, next to a hard crash on most real-world fonts if the built-in shaping were used instead. - `penpot_measure_text` matches Penpot custom/team fonts by family name (case-insensitive) and weight. If a font variant exists in multiple styles (normal/italic) for the same weight, the "normal" style is preferred; if your use-case requires a specific non-normal style for measurement, this is not yet controllable via the tool's input parameters. ## Possible future additions Ideas for further reducing agent friction, roughly in priority order: - [x] `penpot_update_shapes` — edit an existing shape's geometry/fill/stroke/ text in place. (Done — see above.) - [x] `penpot_delete_shapes` — wraps `del-obj`. (Done — see above.) - [x] `penpot_get_shape` — look up one shape (or a small subtree) by id, instead of pulling the whole page via `penpot_get_file_snapshot` and parsing a potentially large JSON blob client-side to find it. (Done — see above.) - [x] `penpot_measure_text` — text `width`/`height` in `penpot_add_shapes` are just numbers the caller has to guess; Penpot only knows real rendered bounds after layout. (Done — see above. Measures against a real fetched Google Font via opentype.js rather than an approximation; see the "Text measurement" note below and `font-metrics.ts` for why it sums per-glyph advances instead of using opentype.js's built-in `getAdvanceWidth`.) - [x] `penpot_clone_shapes` — plain-shape duplication (not the component-instance path already covered by `penpot_add_component_instance`). (Done — see above.) - [x] `penpot_reorder_shapes` — bring-to-front/send-to-back/forward/backward/ before/after, by id. (Done — see above. Note: does *not* wrap `reorder-children` as originally planned — that RPC change type was never actually verified live. Instead it round-trips the parent shape through `add-obj` with a recomputed `shapes` array, the same mechanism `penpot_update_shapes` already uses; `reorder-children` may still work but wasn't worth the extra risk once the `add-obj` approach was confirmed live. One live-only pitfall found along the way: fields like `transformInverse`/`hideFillOnExport` on the object returned by `get-file` are real required fields, not stale camelCase duplicates — they must be renamed to their kebab-case form when round-tripped, not dropped, or `update-file` rejects the change with a malli validation error on `transform-inverse`.) - [x] `penpot_list_components` — enumerate a file's existing components, instead of requiring the caller to have created them itself in the same session or parse the snapshot's `components` map by hand. (Done — see above.) - [x] `penpot_find_shapes` — predicate/name-based search over a page (mirrors the plugin API's `findShapes`), instead of the caller walking the tree itself for "every text shape" or "the shape named X." (Done — see above.) - [x] `penpot_batch` — apply an ordered list of create/update/delete/reorder ops as a single `update-file` change-set. (Done — see above. Ops are applied against an in-memory shadow of the page's shapes, mutated as each op is processed, so a later op sees the effect of every earlier op in the same call — mirroring how `update-file` applies its `changes` array sequentially server-side. This is also what lets a `create` op's caller-chosen `id` be referenced by a later op's `parentId`/`frameId`, or be the target of a later `update`/`delete`/ `reorder`, without an extra RPC round trip in between.) - [x] `penpot_checkpoint` / `penpot_restore_checkpoint` / `penpot_discard_checkpoint` — snapshot shapes before a risky multi-step edit, and restore them after. (Done — see above. Penpot's RPC has no "revert to revn X" primitive, so restore works by diffing current state against the snapshot and replaying corrective `add-obj`/`del-obj` changes as a single `update-file` call, reusing the same camelCase-in/kebab-case-out normalization already verified live for `penpot_update_shapes`/ `penpot_reorder_shapes` — see `restoreShapeAsAddObj` in `shape-builders.ts`. Snapshots are held in the MCP server's own memory, not written to the Penpot file or disk, so a checkpoint doesn't survive a server restart. `penpot_checkpoint` now accepts an optional `pageId`: supply it to scope the snapshot to a single page; omit it for a whole-file checkpoint that covers every page. Restore applies all pages' corrective changes in one `update-file` call, so a multi-step edit that touched multiple pages is fully undone in a single round trip.) - [x] `penpot_align_shapes` / `penpot_distribute_shapes` — the one-click align-left/center/distribute-evenly actions Penpot's own UI has, that this package doesn't. Without them, an agent has to compute pixel positions itself from `penpot_get_shape` results — exactly the kind of arithmetic LLMs get wrong. (Done — see above. Both operate on each shape's `selrect` (its rotation-aware visible bounding box), so rotated shapes line up by what's rendered; align never moves the group as a whole (its reference line comes from the shapes' own extent) and distribute leaves the two endpoints fixed. Aligning/distributing a frame or group moves its whole descendant subtree by the same delta — a container's children have absolute positions, so shifting only the container's own x/y would leave them behind. Reuses the same camelCase-in/kebab-case-out `add-obj` update path already verified live for `penpot_update_shapes`, applied as a single `update-file` change-set.) - [x] Token file support for spacing/radii/shadows, not just `colors` and `fonts`. (Done — see above/Token file schema. Added a `shadows` wire field to `rect`/`frame`/`text` that didn't exist at all before this — verified live against a real instance's `add-obj`/`get-file`: the field is `shadows` (array, back-to-front like `fills`/`strokes`), `style` is `"drop-shadow"` | `"inner-shadow"` (not `shadowType` as the Penpot plugin API's `Shadow` type would suggest), offsets are kebab-case `offset-x`/`offset-y` on write and camelCase `offsetX`/ `offsetY` on read back, and `color` is a nested `{ color, opacity }` object rather than flattened `shadow-color`/`shadow-opacity` keys — see the comment on `Shadow` in `shape-builders.ts`. Every numeric field that previously took a raw number (layout `rowGap`/`columnGap`/ `padding`, `layoutItem` margins/min/max sizes, corner radii `r1`-`r4`) now accepts a `{ token: "name" }` reference resolved against the token file's new `spacing`/`radii` tables, resolved in `content.ts` before reaching `shape-builders.ts` — which stays token-agnostic by design, same seam `resolveColor` already used for fills/strokes.) - [x] Path/ellipse shapes and boolean ops (union/subtract/intersect) in `penpot_add_shapes`. (Done — `circle` is an ellipse bounded by x/y/width/height; `path` accepts an array of `{ command, params }` segments and derives its bounding box automatically from tight cubic-Bézier extrema; `bool` wraps children shapes (added with `parentId` = the bool's id, same pattern as frames) with a `boolType` of `union`, `difference`, `intersection`, or `exclusion` — the visual result path is computed by Penpot's editor when the file is opened, since the boolean geometry engine lives in Penpot's browser-side WASM module rather than on the server.) - [x] Widen `penpot_update_shapes` to cover path/group/circle/svg-raw/image/bool (and any other shape type). (Done — `circle` and `bool` round-trip through their dedicated builders (preserving `bool-type` and `shapes`); `path` rebuilds geometry from the existing path content unless a new `content` array is supplied in the patch (x/y/width/height are always derived from content and cannot be set independently); `group` rebuilds geometry and `shapes` without touching children; image/svg-raw and any other type get a generic geometry-only rebuild, with all type-specific fields carried forward from `existing` via the `{ ...existing, ...obj }` merge. Also added `layout` (frame shapes only) and `layoutItem` (any shape) to the patch schema so auto-layout can be set or replaced after creation — same schema as `penpot_add_shapes`. A new `boolType` patch field replaces a bool's operation type in place. `computeShapeGeometry` and `group` are now exported from `shape-builders.ts` and `expandTranslateChanges` in `content.ts` now correctly handles groups and paths in align/distribute subtrees.) - [x] Penpot team/custom font lookup for `penpot_measure_text` — if the requested font family is not found on Google Fonts, all Penpot teams accessible to the configured access token are searched for a matching custom/team font variant (`get-font-variants` → `download-font`). The "normal" style is preferred when multiple variants exist for the same family+weight; if none match anywhere, a combined error message names both sources. (Done — see `font-metrics.ts`:`fetchPenpotFontBytes`; `PenpotFontClient` interface keeps the module decoupled from `rpc-client.ts` so unit tests can supply a plain mock.) - [x] Add a variant to an already-existing component/group. `penpot_add_variant` appends a new variant to an existing variant group container by re-adding the container frame via `add-obj` with the new variant's root id appended to its `shapes` array (the same delete-and-recreate-through-`add-obj` trick used by `penpot_reorder_shapes`, avoiding the `mov-objects` silent-no-op pitfall noted below). The new component is registered in the same `update-file` call. - [x] `penpot_list_pages` / `penpot_rename_page` / `penpot_delete_page` — `penpot_create_page` exists and now so does the rest of the page CRUD: `penpot_list_pages` returns every page's id and name (in order) without pulling the full shape tree; `penpot_rename_page` renames a page in place; `penpot_delete_page` removes it (guards against deleting the last page of a file). Both mutations go through `update-file` with `rename-page` / `del-page` change types, the same single-round-trip path every other content tool uses. - [x] SSO/OIDC-only instance support for `penpot_export_shape` via `PENPOT_AUTH_TOKEN_COOKIE`. (Done — in addition to the existing `PENPOT_LOGIN_EMAIL`/`PENPOT_LOGIN_PASSWORD` password-login path, you can now set `PENPOT_AUTH_TOKEN_COOKIE` to a raw `auth-token` cookie value obtained by completing the OIDC/SSO flow in a real browser. The profile-id is fetched via `get-profile` on first use; if the cookie expires a clear error message explains how to renew it. `PENPOT_LOGIN_EMAIL`/`PENPOT_LOGIN_PASSWORD` takes precedence when both are set. Fully headless OIDC automation — driving the redirect flow without a browser — is still not implemented, as the cookie-passthrough approach covers the SSO gap without adding a Playwright dependency.) - [x] Unit coverage for `rpc-client.ts`, `transit.ts`, and `tools/project-files.ts` — currently zero unit tests, only reachable via the integration suite that's excluded from CI. Mocking `fetch` for status-code branching (204, 401/403 retry, non-2xx → `PenpotRpcError`) would catch regressions in CI instead of only on a manual integration run. - [x] Gradient and image fills — `Fill`/`Stroke` in `shape-builders.ts` only carry a flat `color`/`opacity`; Penpot supports linear/radial gradient fills and image fills, neither reachable from any tool today. Likely the highest-value gap, since most real designs use at least one gradient or image fill somewhere. (Done — `fills` array on every non-text shape (`rect`, `frame`, `circle`, `path`, `bool`) in `penpot_add_shapes`/`penpot_update_shapes`/`penpot_batch` accepts entries of `type` `"solid"`, `"linear-gradient"`, `"radial-gradient"`, or `"image"`. Gradient stops may use `{ token: "name" }` references against the token file's `colors` table. Image fills reference an already-uploaded Penpot media object by `mediaId` UUID — the caller must upload the image to Penpot first (via the Penpot UI or a separate tool). When `fills` is provided it overrides the legacy `fillColor`/`fillOpacity` shorthand entirely; backward compatibility is preserved for all existing callers using `fillColor`/`fillOpacity`. The `Fill` type in `shape-builders.ts` is now a union of `SolidFill`, `GradientFill`, and `ImageFill`; `extractEditableFields` round-trips all three types from `get-file`'s camelCase response back to the kebab-case form `add-obj` expects.) - [x] Image shapes / asset upload — there's no `image` shape builder and no upload-media RPC call anywhere; `image`/`svg-raw` shapes are only handled via a generic geometry-only fallback in `penpot_update_shapes`. Blocks any workflow that needs to bring in photos, icons, or existing SVG art. (Done — `penpot_upload_media` uploads a media asset to a Penpot file and returns `{ id, name, width, height, mtype }`. Three source modes: `filePath` (the MCP server reads a local file and POSTs it as multipart), `url` (Penpot's server fetches the image directly — nothing passes through the MCP server, uses `create-file-media-object-from-url`), or `dataBase64` (base64-encoded bytes, requires `mtype`). The returned `id` is then passed as `mediaId` when calling `penpot_add_shapes` with `type: "image"`; `mediaWidth`/`mediaHeight`/`mtype` come from the same response. The `image` shape builder sets `type: "image"` with a `metadata: { id, width, height, mtype }` block (Penpot's wire format, verified from `schema:image-attrs` in `shape.cljc`) plus the standard geometry and selrect/transform fields. `penpot_update_shapes` now handles image shapes with a dedicated case (instead of the previous generic fallback) and accepts `mediaId`/`mediaWidth`/`mediaHeight`/ `mtype` patch fields to swap the displayed image in place. MIME type is auto-detected from file extension for `filePath` uploads (`.png`→`image/png`, `.jpg`/`.jpeg`→`image/jpeg`, `.svg`→ `image/svg+xml`, `.webp`, `.gif`, `.avif`).) - [x] Opacity/hidden/locked/blend-mode flags (Done — all four fields now available in shape builders and `penpot_update_shapes` schema: opacity (0-1 numeric), hidden (boolean), blocked (boolean), blendMode (string). Extraction via `extractEditableFields` converts wire-format "blend-mode" to camelCase "blendMode" for consistent builder interface. Unit and integration tests verify round-trip through Penpot's RPC API.) - [x] Rich per-range text formatting — `text()` in `shape-builders.ts` always emits a single paragraph with one style run; no per- character-range styling, text-align, line-height, letter-spacing, or text-decoration. (Done — `penpot_add_shapes` and `penpot_update_shapes` both accept a `paragraphs` array on text shapes. Each paragraph sets `textAlign` plus typography defaults (`fontFamily`, `fontSize`, `fontWeight`, `fontStyle`, `lineHeight`, `letterSpacing`, `textDecoration`, `textTransform`, `fills`/`fillColor`); its `ranges` array holds one or more text runs that may individually override any of those fields. Multiple paragraphs produce separate paragraph nodes (line-break boundaries). `growType` (`"auto-width"` | `"auto-height"` | `"fixed"`) and `verticalAlign` (`"top"` | `"center"` | `"bottom"`) are also now settable on text shapes. The legacy `characters`/`fontFamily`/`fontSize`/`fontWeight`/ `fillColor` shorthand is fully preserved for callers that don't need per-range control. `extractEditableFields` now returns a full `paragraphs` array for text shapes so a geometry-only update patch (`x`/`y`/`width`/`height` only) no longer collapses a rich-text shape back to single-paragraph. Verified field names against Penpot's `common/src/app/common/types/text.cljc` `text-node-attrs` / `paragraph-attrs` / `root-attrs`.) - [x] Group/ungroup as first-class tools — `group()` already exists as an internal builder, but nothing exposes grouping existing shapes or ungrouping a group via an MCP tool. (Done — `penpot_group_shapes` takes a `shapeIds` array of sibling shapes (all must share the same parent) and wraps them in a new group at the topmost selected shape's z-order position; the group's bounding box is the union of the children's `selrect`s (rotation-aware bounds). `penpot_ungroup_shapes` takes a `groupId` and dissolves it: each child is reparented to the group's former parent at the group's z-order position (preserving relative child order) and the group shape is deleted. Both are implemented as single `update-file` change-sets — group creation sends `add-obj` for the new group, one `add-obj` per child (to update `parent-id`) and an `add-obj` for the updated parent's `shapes` array; ungroup does the same in reverse then appends a `del-obj`. Requires siblings only — shapes with different parents must be moved to a common parent first.) - [x] Resize constraints — Penpot's `constraints-h`/`constraints-v` (how a shape behaves when its parent resizes) are never set or exposed in `EditableShapeFields` or the update patch schema. (Done — `constraintsH` (`left`/`right`/`leftright`/`center`/`scale`) and `constraintsV` (`top`/`bottom`/`topbottom`/`center`/`scale`) are now accepted by every shape builder (`rect`, `frame`, `text`, `circle`, `path`, `bool`, `group`, `image`), emitted as `constraints-h`/ `constraints-v` in the wire format. Both fields are settable at creation time via `penpot_add_shapes` and patchable via `penpot_update_shapes`/ `penpot_batch`; `extractEditableFields` reads them back from `get-file`'s camelCase response so a partial update patch preserves the existing constraints when neither field is included in the patch.) - [x] Batch/whole-page export — `penpot_export_shape` takes exactly one `shapeId` per call, with no multi-shape or multi-page batch export, and only `png`/`svg` (no PDF). (Done — `penpot_export_batch` accepts either a `shapeIds` array (same `pageId`, any mix of `format`/`scale`) or a `shapes` array where each entry may carry its own `pageId`, `format`, `scale`, and `name` — enabling whole-file exports across multiple pages in a single `POST /api/export` call. Parsing each result's `~:uri`/ `~:mtype`/`~:filename` via `matchAll` on the transit+json response; asset downloads are parallelised. Both tools also accept `pdf` as a format value. Multi-page export was previously gated on the MCP schema, not the exporter-client, which already sent per-spec `pageId`s.) - [x] Shared-library components — `penpot_list_components` and `penpot_add_component_instance` only look at the current file's own `components` map; there's no support for pulling components from a separate connected shared-library file. (Done — `penpot_list_components` now accepts `includeLibraries: true`, which calls `get-file-libraries` to enumerate all linked library files (direct and transitive) and then calls `get-file` on each to read its `components` map; each library component entry carries a `libraryFileId` and `libraryFileName` field in the response. `penpot_add_component_instance` now accepts an optional `libraryFileId`; when supplied, the component's main-instance tree is looked up in that library file instead of the current file, and the cloned instance's root `component-file` field is set to the library file's id (matching what Penpot's own editor writes for cross-file component instances). Note: `get-file-libraries` returns file metadata only — it does not include shape/component data — so a separate `get-file` call per library is necessary to enumerate components; this is the same two-step pattern Penpot's own frontend uses.) - [x] Comments API — `penpot_list_comment_threads` lists all threads for a file; `penpot_get_comments` fetches the replies inside a thread; `penpot_create_comment_thread` pins a new thread to a canvas position (x/y + optional `frameId`); `penpot_create_comment` adds a reply; `penpot_update_comment` edits an existing comment's text; `penpot_resolve_comment_thread` marks a thread resolved or reopens it; `penpot_delete_comment` removes a single reply; and `penpot_delete_comment_thread` removes a whole thread and all its replies. All eight tools go through `PenpotRpcClient` methods that send kebab-case JSON params to the `get-comment-threads` / `create-comment-thread` / `update-comment-thread` / `delete-comment` / etc. RPC endpoints (same call pattern as every other tool). Wire format verified against Penpot's frontend source (`data/comments.cljs`): `position` is a nested `{ x, y }` JSON object; `frame-id` is optional on creation (omit to place on the page root); `is-resolved` controls thread resolution state. - [x] Text search-and-replace across a file — `penpot_replace_text` finds every text shape on a page whose runs contain a literal search string and rewrites all occurrences in a single `update-file` call. Matching is case-insensitive by default (`caseSensitive: true` to override); an optional `limit` caps the number of shapes touched; empty `replacement` deletes matches. Replacement is per text-run (leaf node): a search string that spans two adjacent runs within a paragraph is not matched — this covers the common case where all text is in a single run per paragraph. (Done — regex metacharacters in the search string are escaped so `.` / `*` / `(` etc. are always matched literally, not as pattern operators.) - [x] Cross-page/whole-file undo — `penpot_checkpoint` now accepts an optional `pageId`; omit it to snapshot every page in the file in one call. `penpot_restore_checkpoint` restores all snapshotted pages in a single `update-file` call. Checkpoints still live in server memory and don't survive a restart; persistence across restarts is still not implemented (callers needing that should snapshot via `penpot_get_file_snapshot` themselves). (Done — `Checkpoint` in `checkpoints.ts` now holds a `pages` map (pageId → objects) instead of a single `pageId`/`objects` pair; the restore loop iterates every entry and accumulates all changes before sending one `update-file` call — the same single-round-trip pattern used by `penpot_batch`.) - [x] Fully headless OIDC/SSO login — drive the redirect flow without a browser, instead of requiring `PENPOT_AUTH_TOKEN_COOKIE` to be obtained manually beforehand. (Done — `PENPOT_OIDC_USERNAME` + `PENPOT_OIDC_PASSWORD` trigger a new `'oidc'` auth mode in the exporter client. The server follows Penpot's `/api/auth/oauth/{provider}` redirect chain to the identity provider's login page via plain HTTP (Node.js `http`/`https` modules, no browser dependency), parses the HTML login form heuristically to identify username/email and password fields (including hidden CSRF/state fields, which are preserved and re-submitted verbatim), and captures the resulting `auth-token` cookie. Multi-step flows — where the IdP shows username on page 1 and password on page 2 (Authentik-style) — are handled by a MAX_FORM_STEPS loop that re-parses and re-submits until the cookie appears. 307/308 redirects preserve POST method+body; 301/302/303 switch to GET per RFC 7231. The cookie jar correctly captures Penpot's own state/CSRF cookies set on the initial redirect so they are forwarded to the IdP's callback. Re-logs in automatically on 401/403 (same as password mode). `PENPOT_OIDC_PROVIDER` controls the provider name (default `"oidc"`). Does not work for JavaScript-driven IdP login pages — use `PENPOT_AUTH_TOKEN_COOKIE` for those. Unit-tested via injected mock fetcher; integration test requires a live OIDC provider and is not in CI.) - [x] Checkpoint persistence across server restarts — checkpoints (`penpot_checkpoint`/`penpot_restore_checkpoint`) currently live only in the MCP server's own memory and are lost on restart. Persisting them to disk (or letting the caller supply a checkpoint id to save/load) would let a long-running multi-step edit survive a server restart mid-way through. (Done — set `PENPOT_CHECKPOINTS_PATH` to a local directory; the server writes each checkpoint as `<uuid>.json` into that directory and reloads all files from it at startup. `initCheckpointStore(dir)` is called once in `server.ts` main; `saveCheckpoint` is now async and awaits the `writeFile` so the caller knows immediately if the write failed; `deleteCheckpoint` is also async and removes the corresponding file from disk. No change to the in-memory behaviour when the env var is unset.) - [x] Single-call multi-page batch export — `penpot_export_batch` exports multiple shapes on one page in a single call; exporting across pages still requires one call per `pageId`. Worth revisiting if batch export becomes a bottleneck for whole-file exports. (Done — `penpot_export_batch` now accepts either `shapeIds` (single-page shorthand, backward-compatible) or a `shapes` array where each entry carries its own `pageId`, `format`, `scale`, and optional `name`. The exporter-client already sent per-spec `pageId`s in a single `POST /api/export`; the only change was widening the MCP tool's Zod schema to expose this capability. Cross-field validation (at least one of `shapeIds`/`shapes`; not both; `pageId` required for `shapeIds`; every `shapes` entry has a `pageId` either per-entry or via the top-level default) is done with `.refine()` on a separate `exportBatchInput` schema while `exportBatchBaseSchema` (the raw `ZodObject`) is passed to the MCP SDK's `inputSchema` to preserve `.shape`.) - [x] Stale-write detection via `revn` — every write tool (`penpot_update_shapes`/`penpot_batch`/`penpot_restore_checkpoint`/etc.) currently sends `update-file` blind, without checking the file's current `revn` (revision number) first. If a human has the file open in the Penpot editor and edits concurrently with an agent session, whichever write lands second silently overwrites the other with no error. Penpot's own `update-file` RPC takes a `revn` and is expected to reject a change-set built against a stale one; today nothing here reads or checks it beforehand. Fix is to fetch current `revn` before writing and surface a clear "file changed underneath you, re-fetch and retry" error on rejection, rather than actually merging concurrent edits (which would need Penpot's own operational-transform logic). (Done — `PenpotStaleWriteError` is thrown by `updateFile` in `rpc-client.ts` whenever the `update-file` response includes a non-empty `lagged` array, meaning Penpot applied change-sets from another session before ours. Penpot's collaborative engine still applies our write on top, so the write succeeds at the HTTP level, but the error surfaces the concurrent-edit situation with a clear message that names the new `revn` and tells the caller to re-fetch via `penpot_get_file_snapshot` before making further edits. Applies to all write tools automatically — `penpot_add_shapes`, `penpot_update_shapes`, `penpot_delete_shapes`, `penpot_batch`, `penpot_restore_checkpoint`, `penpot_group_shapes`, `penpot_ungroup_shapes`, `penpot_clone_shapes`, `penpot_reorder_shapes`, `penpot_align_shapes`, `penpot_distribute_shapes`, page CRUD, etc. — since they all go through `updateFile`. `PenpotStaleWriteError` carries `laggedCount` (number of concurrent change-sets) and `result` (the full `update-file` response, including the new `revn`) so callers that need the new revision can read it from the error rather than requiring an additional round trip.) - [x] Version history / branching support — `penpot_list_file_snapshots` lists all named snapshots for a file (both user-created versions and system auto-backups); `penpot_create_file_snapshot` saves the current state as a named version (optional `label`; Penpot generates a timestamp label when omitted); `penpot_restore_file_snapshot` rolls the live file back to any listed snapshot (Penpot automatically creates a system backup of the current state before applying the restore, so a restore is itself undoable by restoring the most-recent system entry); `penpot_rename_file_snapshot` renames a user-created snapshot; `penpot_delete_file_snapshot` removes one; `penpot_lock_file_snapshot` / `penpot_unlock_file_snapshot` pin/unpin a snapshot against accidental deletion (only the snapshot's creator can lock/unlock, and only user-created snapshots support locking — system backups expire automatically). `penpot_get_file_snapshot_data` returns the full file content at a specific snapshot for read-only inspection or comparison without touching the live file. Wire format verified against `backend/src/app/rpc/commands/files_snapshot.clj` and `backend/src/app/features/file_snapshots.clj`. - [x] Component-instance drift/override visibility — Penpot's composition model is tokens → elements → components (with variants) → screens built from component instances, and today the tools that read shape state (`penpot_get_shape`, `penpot_find_shapes`) don't surface where a shape sits in that hierarchy. A component instance's `shape-ref` link to its main component (and whether it has drifted — fields overridden since being placed, or fully detached) is invisible: an agent editing an instance via `penpot_update_shapes` can't currently tell "this edit creates a per-instance override" from "this edit changes a raw shape," which matters for keeping instances honestly in sync with their component rather than silently diverging the way ad-hoc UI edits can. Scope: extend `penpot_get_shape`/`penpot_find_shapes` to report link state (`linked` / `detached` / not-an-instance) and, when linked, which fields differ from the main component's current definition — read-only visibility first; explicit detach/relink tools and discovery-first tool guidance (checking `penpot_list_components` before creating shapes that duplicate an existing component) are possible natural follow-ons once drift is at least visible. (Done — both `penpot_get_shape` and `penpot_find_shapes` now include component link state in their output. `penpot_get_shape` adds a top-level `componentInfo` field with `linkState` (`"linked"` / `"detached"` / `"not-an-instance"` / `"main-component-root"`), the `componentId` and `componentFileId` when present, `mainInstanceId` / `mainInstancePage` for same-file linked instances, and a `driftedFields` array (camelCase field names) listing which visual properties on this instance differ from the main component's current definition — empty array means fully in sync. `penpot_find_shapes` adds `linkState` and `componentId` to each match entry, plus `driftedFields` for same-file linked instances. Drift is compared over: `name`, `fills`, `strokes`, `shadows`, `opacity`, `hidden`, `blendMode`, `width`, `height`, `constraintsH`, `constraintsV`, and `content` (text shapes); position `x`/`y` is excluded since every placed instance lives at a different canvas location by design. Library components (`componentFile` ≠ current file) report `linkState: "linked"` but `driftedFields` is omitted since the library file's pages would require an extra RPC call — use `penpot_get_shape` on a library instance root, then follow its `mainInstanceId`/`mainInstancePage` manually if cross-file drift is needed.)