Potencialize seu agente
O comando do próprio publicador. Não é um endpoint do PlugMCP.
Host a copy with our keys and logs.
npx -y @figwright/[email protected]O Claude Code não tem link de instalação para um comando local. Copie o comando abaixo e execute-o em um terminal.
claude mcp add figwright-mcp -- npx -y @figwright/mcp@0.7.0Execute em um terminal.
{ "mcpServers": { "figwright-mcp": { "command": "npx", "args": [ "-y", "@figwright/[email protected]" ] } }}claude_desktop_config.json
URL remota ou um comando na sua máquina? Como as duas instalações diferem
Rodar no PlugMCP
A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.
AbrirFigwright connects an MCP server to a Figma plugin over a local WebSocket relay, so an AI agent (Claude Code, Cursor, Codex, or any other MCP client) can work with Figma instead of just looking at it.
It works in both directions:
Read: turn a Figma selection into framework-aware code, grounded on faithful, de-duplicated design context (layout, typography, variables, components). Write: author and edit the canvas directly, from frames and text to auto-layout, styles, variables, components, whole screens. Everything runs on your machine: the server, the relay, and the plugin. Your designs are never sent anywhere.
You need an MCP client (Claude Code, Cursor, …), Node.js 20.19+ or 22.12+, and Figma. The free Figma tier is enough, though the desktop app is needed to import the plugin. The server runs via npx as its own process, so its Node version is independent of the one your project builds with; Node 18/21 and 22.0–22.11 are not supported.
For Claude Code, add this to your .mcp.json (other clients use the same shape):
{
"mcpServers": {
"figwright": {
"command": "npx",
"args": ["-y", "@figwright/mcp@latest"]
}
}
}
npx fetches and runs the published server, so no global install is needed.
The plugin isn't on the Figma Community marketplace yet, so install it from the latest release:
manifest.json.Open the Figwright plugin in Figma (Plugins → Development → Figwright). It connects to the local server automatically and shows Connected. Ask your agent to run ping to confirm the link.
The skills make agents reach for Figwright at the right moment and follow the grounded workflows:
npx skills add awdr74100/figwright/skills
With a frame selected in Figma, prompt your agent:
Code this Figma selection as a React component.
or, the other direction:
Build a pricing section in Figma from this spec.
Each release ships the server and the plugin together, so update both. The skills are optional and update the same way you installed them.
1. Restart the server. With the @latest config above there is nothing to install, because every launch fetches the newest release. A session that is already open keeps the server it started with, so new tools don't appear until you restart it: in Claude Code, run /mcp, pick figwright and choose Reconnect (or restart Claude Code); in other clients, restart the client. Do this in each client you use Figwright from.
If you installed the package instead of using @latest (see the FAQ), update it before restarting: npm i -D @figwright/mcp@latest, or npm i -g @figwright/mcp@latest for a global install.
2. Replace the plugin. Download the zip from the latest release, unzip it, and copy its manifest.json and dist into the folder you imported the plugin from, replacing the old ones. Figma runs a development plugin straight from that folder, so you don't import it again. Close the plugin and run it again.
3. Update the skills. Run npx skills update. Agent sessions you start after that use the new version.
To confirm, open the plugin's Debug tab: it lists the server and plugin versions side by side. If the plugin is still too old for the server, the panel header says so, and so does every tool result (see the FAQ).
Agent skills orchestrate Figwright's tools. They are model-invoked: your agent loads one automatically when the task matches its description.
Install across any supported agent with the skills CLI:
npx skills add awdr74100/figwright/skills # both
npx skills add https://github.com/awdr74100/figwright/tree/main/skills/figma-codegen # one
[!NOTE] Skills need the
@figwright/mcpserver connected. On their own they have no tools to drive.
Figwright exposes 135 MCP tools in three groups:
list_files / use_file for working across more than one open Figma file at once.batch tool to apply many edits at once.get_design_context for faithful, de-duplicated design context, and component_map / token_map / icon_map, which join Figma data to your codebase so codegen reuses what you already have; plus design_diff, which reports what changed in a design against a saved baseline so you update only the affected code.[!TIP] Your MCP client lists every tool at connect time, which is always the authoritative, up-to-date catalog.
The Figma-side plugin isn't a black box. It shows every call as it happens, lets you inspect the exact payload sent to the model, and surfaces its own connection health. And it follows your Figma theme, light or dark. The window is yours to arrange. Drag the bottom-right corner to resize it. A taller panel keeps more of the log in view, and the size is remembered next time you open it. Or put it away: Run in background, in the panel header right under Figma's own ✕, hides the panel while the connection stays live, so a long-running agent keeps working. Run the plugin again to bring it back. The ✕ above it closes the plugin instead, connection and all.
Your MCP client launches the @figwright/mcp server and talks to it over stdio. The server relays each tool call over a local WebSocket to the Figwright plugin, which carries it out through Figma's Plugin API. Every agent runs its own server process; the processes elect a leader that holds the plugin connections, and the rest forward to it. The plugin runs in every file you open it in, so several agents can each work in their own file at once, and the whole path is built to ride out dropped sockets, leader handovers and long reads:
┌─────────────────────────────────────────────────────────────────────┐
│ MCP CLIENTS · each agent's client launches its own server │
│ Claude Code · Cursor · Claude · any MCP-capable client │
└─────────────────────────────────────────────────────────────────────┘
│ MCP protocol over stdio
▼
┌─────────────────────────────────────────────────────────────────────┐
│ @figwright/mcp · the server processes elect one leader │
│ │
│ LEADER (holds every plugin connection) │
│ • WebSocket relay on 127.0.0.1:3055, Host- and Origin-checked │
│ • routes each agent to the file it claimed with use_file, │
│ otherwise to the file the user was last active in │
│ • session resume: a dropped plugin has 30 s to reconnect, and │
│ calls bound for it wait instead of failing │
│ • "busy ≠ dead" heartbeat: a busy plugin isn't taken for dead │
│ • endpoints: /ws (plugins) · /ping (health) · /rpc (followers) │
│ /abdicate (hand over to a newer build) │
│ │
│ FOLLOWERS │
│ • forward tool calls to the leader over HTTP /rpc │
│ • retry a call caught in a leader handover │
│ • take over automatically if the leader exits, and ask an older │
│ leader to step down once it goes idle │
└─────────────────────────────────────────────────────────────────────┘
│ local WebSocket · msgpack (binary)
▼
┌─────────────────────────────────────────────────────────────────────┐
│ FIGMA (desktop or browser) · one plugin per file it's open in │
│ │
│ ┌─────────────────────────────────────────────────────────────────┐ │
│ │ Figwright plugin │ │
│ │ • UI (Vue 3 iframe): WebSocket client, heartbeat, reconnect │ │
│ │ • sandbox: executes Figma Plugin API calls │ │
│ │ – replays a retried write instead of applying it twice │ │
│ │ – long reads yield every ~40 ms to keep Figma responsive │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ │ Figma Plugin API │
│ ▼ │
│ Canvas │
└─────────────────────────────────────────────────────────────────────┘
By design Figwright is provider-first: rather than a fixed compiler pipeline, the tools surface honest design context and let the model generate code that matches your codebase. The figma-codegen skill encodes this approach.
Figwright runs entirely on your machine: your client launches the server over stdio, the server relays to the plugin over a WebSocket on 127.0.0.1:3055, and nothing is sent anywhere else. The plugin uses only Figma's public Plugin API, so it reaches the file you have open and nothing beyond it.
Loopback is not on its own a boundary, since a web page you visit can still reach a local port, so the relay gates every request on two headers a page cannot forge: Host, which must name loopback (this is what stops DNS rebinding), and Origin, which admits the plugin's sandboxed handshake and refuses browsers everywhere else. The leader's HTTP endpoints additionally require a media type that cannot be sent without a CORS preflight. See MCP Security Best Practices for the wider picture, and SECURITY.md for Figwright's threat model, what is in and out of scope, and how to report a vulnerability privately.
Figwright is not a substitute for reviewing what your agent does. Its write tools change your Figma file and its export tools write files to paths the agent chooses; an agent acting on a malicious design or a prompt-injected instruction can misuse both. Your MCP client's tool-approval controls are the boundary that matters.
Both come down to how your MCP client launches the server: it spawns the command directly, not through your interactive shell, so it inherits none of what your shell sets up. That bites hardest when Node is managed by a version manager (fnm, nvm, asdf, volta, mise), since those configure PATH and npm from shell hooks that only run in a real terminal. It is not specific to Figwright; it affects any npx-launched MCP server. There are two symptoms, with two different fixes.
command not found: the client can't find npx / node on its PATH.
Use an absolute path. In a normal terminal run which npx (or which node) and use that full path as command:
{
"mcpServers": {
"figwright": {
"command": "/Users/you/.local/share/fnm/node-versions/v24.x.x/installation/bin/npx",
"args": ["-y", "@figwright/mcp@latest"]
}
}
}
Or pass PATH through env. If your client supports a per-server env, add your version manager's bin directory to env.PATH.
-32000 / "Connection closed" / it just never connects: npx runs, but the server exits before the handshake.
npx … @latest re-resolves the package from the registry on every launch. In a directly-spawned environment that step can fail or stall (empty or different npm config, a corporate proxy or private registry that is not configured there, or no network), so the process dies before MCP connects and the client reports the connection as closed. (A missing node for the binary's shebang lands here too.)
The fix is to install the package so launch needs no registry fetch:
As a project dependency, the quickest unblock. Install it, then drop @latest from your config. The @latest tag is what forces the registry round-trip; without it, npx uses the copy already in node_modules (a project-scoped config like Claude Code's .mcp.json runs from your project root):
pnpm add -D @figwright/mcp # or: npm i -D @figwright/mcp
{
"mcpServers": {
"figwright": {
"command": "npx",
"args": ["-y", "@figwright/mcp"]
}
}
}
Or globally, pinned to the binary. Install once, then point command straight at it, with no npx and no per-launch resolution. Use the absolute path from which figwright-mcp:
npm i -g @figwright/mcp
which figwright-mcp
{
"mcpServers": {
"figwright": {
"command": "/absolute/path/to/figwright-mcp"
}
}
}
The server is launched by your MCP client, so it only runs while that client is open. Check that:
ping);127.0.0.1);The plugin's Debug tab lists both versions side by side, so a mismatch is visible in one place.
Mostly you don't need to look. The two halves update through different channels — the server re-resolves itself on every launch via npx @latest, while the plugin is a zip you imported by hand and then stop thinking about — so drifting apart is the normal state here rather than an edge case. It is also a silent one: a handler that predates an argument ignores it without erroring, so a write can report success having done only part of what was asked. When your plugin is old enough for that, the panel says so and tells you how to update (Updating has the steps), and every tool result tells your agent the result is unverified.
It stays quiet on a difference that cannot bite — a plugin a version behind a server that changed no arguments is fine — so when the warning does appear it is worth acting on.
No. Figwright talks to Figma through a plugin, so the free tier is enough. No Dev Mode seat or paid tier required.
It runs in both, with less available than in Figma Design, because those editors give plugins less rather than because Figwright holds anything back.
get_metadata reports the editor (editorType / mode), and any tool that fails because of the editor says so in its error, so an agent can re-plan rather than retry.
Yes. Several MCP servers can share a single plugin via leader/follower election: one leads, the others follow, with a graceful handoff if the leader goes away.
Yes, once each agent claims its file.
By default calls follow whichever file you last touched, so switching tabs switches what the agent sees — the right behaviour for one agent, and the wrong one for two, since the agent whose file isn't in front would silently get the other file's nodes. Whenever more than one file is open and an agent hasn't claimed one, every result it gets says so, so it can claim one before building anything on the wrong file.
list_files shows every file that currently has the plugin open, and use_file claims one for that agent:
> use the marketing site file
→ use_file({ fileName: "Marketing Site" })
The claim belongs to that agent's own server process, so it never affects the other agent, it survives closing and reopening the plugin panel, and calls keep reaching the file even while its tab sits in the background. That process is also the unit: one per MCP client, so the agents have to be separate clients — two editors, or two terminals. Everything inside one of them, subagents included, shares a server and therefore shares a claim. If two open files share a name (x and a second x), use_file refuses the name and asks for the sessionId that list_files prints, rather than guessing. Release it with use_file({ release: true }) to go back to following the foreground file.
Contributions are welcome. See CONTRIBUTING.md for how to get set up and open a pull request, and AGENTS.md for the architecture, repo layout, tech stack, and conventions.
figwright follows the -wright tradition, an old English word for a maker or craftsman: a playwright writes plays, a shipwright builds ships, a wheelwright, wheels. The name is a nod to Playwright, which automates the browser. Where Playwright drives the browser, Figwright drives Figma, a maker of designs that both reads the canvas and crafts work back onto it.
MIT © Roya
Free, two-way Figma MCP server. Turn designs into framework-aware code, and push code back to the canvas. Works with Claude Code, Cursor, Codex, and any MCP client.
{ "mcpServers": { "figwright-mcp": { "command": "npx", "args": [ "-y", "@figwright/[email protected]" ] } }}Ferramentas
Ainda não há lista de ferramentas. Servidores remotos recebem uma após a primeira verificação de saúde.
Perguntas frequentes
Copie nesta página a configuração stdio para Cursor, Claude Desktop, Claude Code ou VS Code. Ela usa a instalação do publicador, não um proxy do PlugMCP.
Este registro não lista nenhuma variável de ambiente obrigatória.
@figwright/mcp roda localmente via stdio.
Última verificação: 2026-11-14. Free, two-way Figma MCP server. Turn designs into framework-aware code, and push code back to the canvas. Works with Claude Code, Cursor, Codex, and any MCP client.