Figwright: A Two-Way Figma MCP Server That Skips the Dev Mode Seat

The Dev Mode paywall Figwright Is Built Around

Figma's official Dev Mode MCP sits behind a paid Dev Mode seat. Figwright's README states its position plainly: it "pairs with a Figma plugin, not a Dev Mode seat," and the free Figma tier is enough. That single constraint explains most of the architecture. Because there is no paid server-side integration to call, Figwright has to reach the canvas through a plugin the user installs themselves, and it has to relay between that plugin and an agent running on the same machine. The audience is therefore narrow and specific: teams already using Claude Code, Cursor, Codex, or another MCP client, who want design-to-code and code-to-design in the same session, and who are willing to import a plugin from a manifest instead of clicking install in the Figma Community marketplace. If your team already pays for Dev Mode and only needs one-way reads, the case for switching is weak.

Server, Relay, Plugin: Where the Data Actually Goes

Three processes are involved. The MCP server runs as its own process via npx, so its Node version is independent of whatever your project builds with. The Figma plugin runs inside Figma and connects to that server automatically. Between them sits a local WebSocket relay. The README is explicit that the server, the relay, and the plugin all run on your machine and that designs are never sent anywhere, which is the strongest structural claim in the repository and the one worth checking against your own network policy before rollout. The plugin is not opaque: it shows every call as it happens, lets you inspect the exact payload sent to the model, and surfaces its own connection state. That inspectability matters more than it sounds. When an agent produces wrong code from a design, the payload view is where you find out whether the design context was wrong or the model was.

113 Tools, and Why That Number Is a Design Decision

Figwright exposes 113 MCP tools in three groups. Read covers selection, node inspection, styles, variables, components, fonts, reactions, motion state, screenshots, original image-fill assets, PDF export, and video export of animated frames in MP4, GIF, or WebM, plus list_files and use_file for working across more than one open Figma file. Write covers frames, text, shapes, auto-layout, effects, styles, variables, components including their boolean, text, and instance-swap properties, pages, reactions, and Motion keyframes, plus a batch tool for applying many edits at once. Grounding is the interesting group: get_design_context returns de-duplicated design context, component_map, token_map, and icon_map join Figma data to your codebase, and design_diff reports what changed against a saved baseline so you update only the affected code. The README notes that your MCP client lists every tool at connect time and that this list is authoritative. That is a practical warning as much as a feature: 113 tool definitions consume context in every session, whether or not you touch them.

Provider-First Codegen and the Maps That Make It Work

The differentiator Figwright claims is that it detects your real stack, meaning framework plus styling system, and reuses existing components, tokens, and icons rather than emitting generic markup. The mechanism behind that claim is the three maps. component_map, token_map, and icon_map join Figma data to your codebase, and get_design_context supplies the de-duplicated context the model reasons over. This is a meaningfully different approach from tools that translate a frame into standalone JSX and leave the reconciliation to you. It is also the part most dependent on your repository being legible to the mapper. A codebase with inconsistent component naming or tokens defined in several places gives the maps less to join on, and the README does not describe what happens when a component in Figma has no counterpart in code. Treat the reuse claim as conditional on your codebase, not as a property of the tool.

Getting It Running: The Five Steps in the README

Prerequisites are an MCP client, Node.js 20.19+ or 22.12+, and Figma. The README states that Node 18, 21, and 22.0 through 22.11 are not supported, which is a hard gate rather than a suggestion. First, add the server to your client. For Claude Code, the README gives this shape in .mcp.json, and other clients use the same shape:

{ "mcpServers": { "figwright": { "command": "npx", "args": ["-y", "@figwright/mcp@latest"] } } }

Second, install the plugin. It is not on the Figma Community marketplace, so you download the plugin zip from the latest GitHub Release, unzip it, and in the Figma desktop app use Menu, then Plugins, then Development, then Import plugin from manifest, and pick the unzipped manifest.json. The desktop app is required for this step. Third, open the plugin from Plugins, then Development, then Figwright; it connects automatically and shows Connected. Ask your agent to run ping to confirm the link. Fourth, optionally install the skills with npx skills add awdr74100/figwright/skills, or target one skill by its tree URL. Fifth, select a frame and prompt the agent, for example to code the selection as a React component, or to build a pricing section in Figma from a spec.

The Plugin Is Not in the Marketplace, and That Shapes Upgrades

The README states the plugin is not on the Figma Community marketplace yet, so installation goes through a downloaded zip and a manifest import. That has a maintenance consequence the README does not spell out but the workflow implies: updating the plugin means repeating the download and import, not accepting a marketplace update. The server side is easier, because npx fetches @figwright/mcp@latest at launch, so every client start pulls the newest published version unless you pin it. Those two halves can drift. A pinned server with a stale plugin, or a latest server with a plugin from an older release, is a plausible failure mode, and the README offers no compatibility matrix between server and plugin versions. The release cadence visible in the repository is roughly monthly across v0.3.0, v0.4.0, and v0.5.0, so drift is a real possibility rather than a theoretical one. Pinning the server version in .mcp.json and re-importing the plugin from the matching release is the conservative pairing.

Skills, Grounding, and What Happens Without Them

Two skills ship with the project: figma-codegen, which turns a selection into framework-aware code grounded on your stack and existing components, and figma-build, which builds a Figma design from code or a description while reusing the file's existing components and styles. They are model-invoked, meaning the agent loads one automatically when a task matches its description rather than you calling it by name. The README carries a note worth reading twice: skills need the @figwright/mcp server connected, and on their own they have no tools to drive. So the skills are orchestration, not capability. Skipping them is survivable, since the 113 tools remain callable directly, but you lose the grounding workflow that makes codegen reuse your components. Installing them costs one command and adds a layer whose failure mode is silent: an agent that does not load the skill will still produce plausible code, just less grounded code, and nothing in the transcript will flag the difference.

Licence, Maintenance, and the Local-Only Boundary

Figwright is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are preserved. This is not legal advice; if you fork the skills or vendor the server, read the LICENSE file in the repository. Maintenance cost concentrates in three places. The server updates itself through npx unless pinned. The plugin updates manually through a zip. And the 113-tool surface grows with each release, which means the context cost at connect time grows too. The local-only design is the boundary that matters most for adoption decisions: the README states the server, relay, and plugin all run on your machine and designs are never sent anywhere, but the agent itself is a separate system with its own data handling, and Figwright's local guarantee does not extend to it. If your constraint is that design data must not leave your network, the plugin and relay satisfy that. The prompt you send to Claude Code or Cursor does not.

Editorial conclusion

Adopt Figwright if you are on Figma's free tier, already run an MCP client, and want the agent to write to the canvas rather than only read from it. Do not adopt it if you need a marketplace-installed plugin, cannot run Node 20.19+ or 22.12+, or want a small, auditable tool surface. Verify first that your Node version is inside the supported range, that the plugin imports from manifest.json in the Figma desktop app, and that ping returns Connected before you build any workflow on top of it.

Official sources

1. awdr74100/figwright on GitHub
2. Issues
3. License: MIT
4. README
5. Releases