Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LAYERWRIGHT_PORTNoThe port used for the Figma plugin connection. There is one Figma plugin connection per port, so parallel sessions need separate ports.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
figma_statusA

Check whether the Figma bridge plugin is connected, which file/page is open, the current selection, and whether a Design System scan is cached. Cheap; call first.

figma_scan_design_systemA

Scan the open Figma file for components, component sets/variants/properties, variables (+modes), text/paint/effect styles and library components used in the file. Normalizes, infers semantic roles, caches to disk, and returns a COMPACT summary (not the full dump). Use refresh=true after the DS changed.

figma_get_design_contextA

Retrieve ONLY the Design System parts relevant to a task (components with variants/properties, spacing/color/radius tokens, text styles, and known code mappings). Use before writing a Design Plan. Example task: 'password reset flow: email, OTP, new password, success'.

figma_inspectA

Read Figma nodes: the selection (default), the current page (top level) or a node id. format: tree (default; compact snapshot of layout, fills, bound variables, text styles, instances), summary (counts, instances per component, top-level children; cheap for big frames), text (every text layer, flat), instances (every instance with variants, props and overrides, flat), plan (the subtree as a Design Plan you can edit and send to figma_preview_plan: clone, refactor, or implement in code). Big answers are capped; use summary, a smaller depth, or offset/limit.

figma_preview_planA

Validate a Design Plan (Design DSL JSON) with Zod, resolve every component/variant/property/token against the cached Design System, and return a planId + human-readable summary WITHOUT touching Figma. Invalid plans or unresolved components return structured errors with suggestions — fix the plan and preview again.

import_html_to_planA

Convert an HTML page or folder (e.g. a Claude Design standalone HTML export) into an editable Design Plan: flexbox → Auto Layout, colors, borders, radii, shadows, gradients, fonts, text (incl. RTL), images and SVG icons. With a scanned Design System, buttons/inputs/links become real DS components. Returns a planId for figma_execute_plan, exactly like figma_preview_plan. Nothing is sent to Figma yet.

figma_execute_planA

Execute a previously previewed plan in Figma (native frames, Auto Layout, component instances, variables, styles). One undo step. Rolls back fully on failure. Automatically verifies the result against the plan. Requires approved=true when the plan writes into an existing node.

figma_verifyA

Re-inspect the nodes created by an executed plan and report structural mismatches against the plan (missing nodes, wrong component/variant, text, layout, unbound tokens). Use after the user edited things or before implementing code.

figma_analyze_designA

Mode B. Inspect the selected frame (or node id), compare it to the Design System, and propose NON-destructive transformations: custom buttons/inputs → DS instances, raw spacing/radius → tokens, raw colors → color variables, raw text → text styles, manual layout → Auto Layout. Returns an analysisId + grouped summary. Nothing is changed.

figma_apply_transformationsA

Apply transformations from figma_analyze_design. REQUIRES approved=true, which you may only set after the user explicitly approved. Pass ids to apply a subset (default all). Replaced originals are hidden and renamed, never deleted. One undo step.

figma_pagesB

Create (or reorder) pages in the open Figma file, in the given order. Existing pages with the same name are reused; an empty default page is renamed instead of kept.

figma_import_htmlA

Import an HTML prototype into Figma at full fidelity for almost no tokens: renders it in headless Chrome, serializes the painted result (boxes, colors, gradients, shadows, radii, text, inline SVG) and builds it on a page. With no targets, every screen on a review board (nested .sc-host) is imported and named by its label. Use dryRun to list screens first.

figma_foundationsA

Create or update Design System foundations in the open file: a variable collection (COLOR and FLOAT variables, e.g. "color/brand/deep-teal": "#176B66", "radius/media": 20), text styles, colour styles (a hex, a gradient, or bound to a colour variable so the style follows the token), effect styles (shadows, layer/background blur) and grid styles (columns, rows, square grid). Idempotent by name. Rescan the DS afterwards.

figma_export_imageA

Render a Figma node as an image you can look at: use it after every build or edit to check the result visually (empty instances, wrong sizes and wrong variants are obvious in a picture). With compareWith, the source HTML is screenshotted in headless Chrome too, and you get both images, a diff heatmap and the share of changed pixels.

figma_editA

Change existing layers in one undo step: rename, move (to a parent, section or page), duplicate, set (visible, position, size, opacity, text, instance properties), delete, resizeToFit (sections grow to their content), prototype (click/hover/after-delay interactions: navigate, overlay, swap, scroll-to, back, close, url, and change-to between variants for interactive components, with transitions), flow (a prototype starting point), swap (an instance to another component or variant; overrides are kept), bind (a variable to fills, strokes, gap, padding, radius, size, opacity), style (a fill, stroke, text or effect style), annotate (native Figma annotations for dev handoff: markdown, measured properties, a category), group / ungroup, boolean (union, subtract, intersect, exclude or flatten shapes), and componentize (turn existing frames into a component, several components, or one component set with variants; works on copies by default, and can expose text layers as TEXT properties). Ops run in order and can use "$n" for the node made by op n. Changing or deleting existing nodes needs approved=true; without it, delete only hides and renames the node (🗑).

figma_migrateA

Move every instance of one component (set) to another, e.g. from an old Accordion set to the new one, or from one library to another: each instance is swapped to the matching variant (same property values; map renamed properties or values), keeping its overrides. Without approved it only reports what would change (instances per target variant, and the ones with no match). With approved it applies everything in one undo step.

layerwright_memoryC

What Layerwright remembers in this project (.layerwright/memory.json, shareable with the team): font substitutions and component mappings reused by imports, which of several same-named components the user chose, the user's notes, and recurring problems with hints. Save a note whenever the user corrects you ('use the Fa styles for Persian text'), so the next session starts from it.

figma_cleanupA

List what Layerwright created (by session, run or node ids) — e.g. leftovers from failed attempts — and, with approved=true, remove it. Default: this session, list only.

figma_selectA

Select and zoom to node ids in Figma (to show the user what was created or will change). Switches to the page of the first node.

code_scan_componentsA

Scan the codebase (React/Next) for exported UI components, framework/Tailwind/shadcn signals, and suggest Figma↔code mappings by name. Use before implementing a Figma design so existing components are reused.

code_mappingC

Read or upsert the Figma component → code component mapping stored in .layerwright/mapping.json (commit it to share with the team).

code_verify_usageB

Verify an implementation file against the design: are the mapped code components for the plan's Figma components used? Flags raw / duplicates and arbitrary Tailwind values.

Prompts

Interactive templates invoked by user choice

NameDescription
figma_designThe whole Layerwright workflow: pick the job, set up, then HTML → Figma, build, change, or Figma → code.
html_to_figmaImport an .html file or folder as editable Auto Layout, then use the Design System.
build_in_figmaBuild screens, flows and prototypes from a brief with the file's Design System, then critique and fix.
change_figmaEdit, componentize, apply or audit the Design System, wire prototypes, annotate or migrate existing layers.
figma_to_codeRead a frame with its components and tokens, implement it, and verify the code uses the mapped components.

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 22 tools

Disambiguation4/5

Most tools target a distinct stage of the Figma workflow (status, scan, inspect, plan/preview/execute, verify, analyze/apply, edit, migrate). A few boundaries blur, notably figma_import_html vs import_html_to_plan and the all-in-one figma_edit overlapping with specialized ops like figma_apply_transformations and figma_migrate, but descriptions differentiate them well.

Naming Consistency4/5

Names are predominantly consistent snake_case with subsystem prefixes (figma_*, code_*, layerwright_*), which reads predictably. The outlier import_html_to_plan breaks the figma_ prefix used by its sibling figma_import_html, and a few tools are bare verbs (figma_inspect, figma_verify), a minor deviation.

Tool Count4/5

22 tools sits in the heavy range, but the scope (Figma bridge, design-system scan/foundations, plan preview/execute/verify, HTML import, code mapping) is genuinely broad and most tools earn their place. Slightly over-stuffed, with the two HTML-import tools and the mega figma_edit the main candidates for consolidation.

Completeness4/5

The surface covers a full design-to-code lifecycle: status/cleanup, DS scan and foundations, node inspection, plan preview/execute/verify, non-destructive analysis/apply, editing, migration, image export, selection, project memory, and code scan/mapping/verification. Gaps are minor, e.g. no explicit design-system element deletion or standalone code-generation output tool.

Maintenance

ActivityMaintained
ResponsivenessWithin a week