# figma-console-mcp: Figma as an API for AI Assistants

> A TypeScript MCP server that gives AI clients read and write access to Figma through a Desktop Bridge plugin, with four connection modes that trade capability for convenience.

**southleft/figma-console-mcp** — Your design system as an API. Connect AI to Figma for extraction, creation, and debugging.

- Repository: https://github.com/southleft/figma-console-mcp
- Website: https://southleft.com
- Stars: 2,373 · Forks: 246
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/southleft-figma-console-mcp

## What figma-console-mcp actually connects

Most Figma integrations stop at reading a file. figma-console-mcp is built the other way around: the README describes it as a Model Context Protocol server that gives AI assistants access to Figma for extraction, creation, debugging, and bidirectional token sync. The intended user is a design systems engineer or a product designer who already works in Figma Desktop and wants an AI client such as Claude Code, Cursor, Windsurf, or Claude Desktop to act on a live file rather than on an exported snapshot.

The capability split is the first thing to understand. The README's comparison table lists 114 tools for NPX and Local Git, 101 for Cloud Mode, and 9 for Remote SSE. Remote SSE is read-only: it can read design data but cannot create components, edit designs, manage variables, or touch FigJam boards. Cloud Mode restores write access for web clients (Claude.ai, v0, Replit) without requiring Node.js, but it does not support real-time monitoring. Only NPX and Local Git expose console and selection monitoring through the Desktop Bridge plugin.

That plugin is the load-bearing part of the architecture. Figma Desktop is a prerequisite for the NPX path, explicitly "not just the web app." If your team works exclusively in the browser, the highest-capability configuration is unavailable to you, and you are choosing between Cloud Mode's 101 tools and Remote SSE's 9.

## How the Desktop Bridge and the four connection modes fit together

The repository layout shows the split clearly: src/ holds the server code, figma-desktop-bridge/ holds the plugin, and wrangler.jsonc plus tsconfig.cloudflare.json indicate a Cloudflare Workers deployment target. The package.json description confirms both: "Local (WebSocket Desktop Bridge plugin) and Cloudflare Workers (paired + remote) modes."

In the local path, the MCP server runs as a Node process and talks to the Figma Desktop Bridge plugin over a WebSocket. The plugin is what actually reaches into the open Figma document, which is why real-time console monitoring and selection awareness only exist in this mode. The cloud path replaces the local process with a Worker, which is how a browser-based AI client can still write to a file: the README calls this the Cloud Write Relay, and it works through cloud pairing.

Remote SSE is the thinnest layer, nine tools, no Node.js, no plugin. It is the right shape for a quick look at design data and the wrong shape for anything that mutates a file. The README's own summary is blunt: Remote SSE is read-only, Cloud Mode unlocks write access, NPX or Local Git gives the full tool set with monitoring.

One detail worth noting for anyone running several Figma integrations at once: every tool response carries `_mcp: "figma-console-mcp"` and errors are prefixed `[figma-console-mcp]`. That is a deliberate answer to attribution ambiguity when an agent has more than one Figma MCP loaded.

## Installing figma-console-mcp with NPX and making a first call

The README recommends NPX for anyone who wants to create and modify designs, and estimates about ten minutes. Prerequisites are Node.js 18+, Figma Desktop, and an MCP client. The package declares `"engines": { "node": ">=18.0.0" }`, so confirm the version first.

```bash
node --version
```

You should see v18 or higher. Then create a Figma personal access token. The README points to Figma's help page on managing personal access tokens and suggests the description `Figma Console MCP`.

The package is published on npm as figma-console-mcp, and package.json exposes a binary of the same name pointing at dist/local.js. The README's setup steps continue past the token creation into client configuration; the excerpt available here is truncated mid-sentence at that point, so the exact JSON block your client needs is not reproduced in this article. Follow the NPX Setup section of the README for the client-specific snippet.

```bash
npx figma-console-mcp
```

When the server starts, your MCP client should list the tools for the mode you configured. The README states the full NPX set is 121 tools including design creation, variable management, and component instantiation. If your client reports nine, you are pointed at the remote endpoint rather than the local server.

For contributors, the repository also documents a Local Git Mode, and package.json provides `npm run dev:local` (tsx src/local.ts) plus `npm test` (jest) for working on the source directly.

## Design System Extraction: turning a codebase into tokens

Version 1.40.0 added seven `figma_ds_*` tools that run in Local Mode and work in the opposite direction from the rest of the server. Instead of reading a Figma file, they scan one or more application codebases and produce a design system from what the code actually does.

The README describes the pipeline in some detail: framework, styling-method, and vendor-layer detection; a usage-ranked component inventory classified as vendored, wrapped, pure-vendor, or bespoke; variant inference from real call sites; duplicate detection; and an architecture pass that separates a UI kit from a design system. The example given is `FollowButton` really being a `Button`, with the missing generic primitives identified as a result.

The token mining is the part with the most specificity. It extracts the app's de-facto styling into DTCG tokens with per-token provenance, covering multi-mode CSS custom properties (`.dark`, `[data-theme]`), SCSS variables, Tailwind config values, shadcn HSL triples, Tailwind utility-class frequency mining valued from the app's own theme, and frequency-promoted raw values. From there it scaffolds a design-system package with token, typography, and iconography showcase pages, wires a Storybook workshop to the app's real theme layers and fonts, and gates the output behind what the release notes call deterministic fidelity evals.

The round trip closes with `figma_import_tokens`: the extracted `tokens/tokens.json` imports into Figma variables. The same release fixed token formatters quoting CSS functional expressions like `cubic-bezier(...)`, which the changelog notes would silently kill transitions and also affected `figma_export_tokens` output. This is server-only, with no plugin re-import required.

## Token sync, audits, and where the tool set gets thin

Bidirectional token sync is the feature most likely to displace an existing pipeline. The README claims it replaces Style Dictionary and Tokens Studio's export pipeline: variables go out to DTCG JSON (legacy or 2025.10 dialect) plus nine more formats, and code-side edits go back into Figma with full apply, meaning creates, renames, alias re-targeting, and replace-gated deletes. The replace-gated delete is the interesting design choice. Deletions are gated rather than immediate, which suggests the authors treat destructive sync as a hazard worth a confirmation step.

Beyond tokens there is a long tail: version history with snapshot diffs, markdown changelog generation, binary-search blame for tracing when a property or variant was introduced, 14 WCAG design checks with conformance level tagging, axe-core code scanning, design-to-code parity checks, and a Lighthouse-style scored design-system health audit across naming, tokens, component metadata, accessibility, consistency, and coverage. FigJam boards and Figma Slides decks are also covered.

The honest limitation is that this is a wide surface with uneven documentation depth. The README excerpt describes the token formatter fix in detail but does not document rollback behavior for a sync apply, and it does not spell out what happens when a rename collides with an existing variable in the target file. Anyone planning to run replace-gated deletes against a production library should treat that as unverified. The tool count itself is also a cost: an agent with 121 tools available has a large selection problem, and the README does not describe any scoping or profile mechanism to narrow the set per task.

## Compared with reading Figma through the REST API

The obvious alternative is scripting against the Figma REST API directly, or using a general-purpose Figma MCP that exposes file reads. The difference is architectural rather than cosmetic.

A REST-based integration reads a snapshot of the document. It can list variables and components, but it cannot create a frame in the open editor, cannot watch the console, and cannot observe what the user currently has selected. figma-console-mcp's local mode runs a plugin inside Figma Desktop and communicates over a WebSocket, which is what makes write operations and real-time monitoring possible at all. The README states this plainly: real-time monitoring and the Desktop Bridge plugin are available in NPX and Local Git, and in Cloud Mode for the plugin but not for monitoring.

The trade is operational weight. A REST script needs a token and an HTTP client. This needs Node.js 18+, Figma Desktop installed, a plugin, and a personal access token. If your goal is to pull a variable list into a build step once a day, the REST API is the smaller commitment. If your goal is to have an assistant create a component set from a variant axes matrix in one call, or to push edited tokens back into a file, the plugin-based approach is doing work the REST API was not designed for. The 9-tool Remote SSE mode is closer to the REST model and is a reasonable middle ground for read-only exploration.

## Maintenance, licence, and what an upgrade costs

The repository is not archived, and the last push was on 2026-09-09, which is recent. Releases have been frequent: v1.40.0 on 2026-08-16, v1.39.1 on 2026-08-02, and v1.39.0 on 2026-08-02. The v1.39.0 release added concurrent multi-file execution, and v1.39.1 was a plugin update banner fix, which is a normal cadence for a project of this size.

The upgrade cost is asymmetric depending on where you sit. Server-side changes ship through npm, and the v1.40.0 notes explicitly say the Design System Extraction work is server-only with no plugin re-import needed. Plugin-side changes such as the v1.39.1 banner fix do require updating the Desktop Bridge plugin, which is the heavier path because it is installed inside Figma rather than pulled from a registry. Budget for plugin updates separately from package updates.

Licensing is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is a permissive arrangement with few strings. Note only that MIT covers this project's code, not Figma's own terms of service or the access rules attached to personal access tokens, and not the licence of any codebase you point the extraction tools at. None of that is legal advice; check your own obligations.

## Conclusion

Adopt figma-console-mcp if your team already lives in Figma Desktop and wants an AI client to read variables, create components, or push token edits back into a file. Skip it if you only need read-only exploration, since Remote SSE covers that with 9 tools and no Node.js install, or if you cannot install Figma Desktop, because the full 121-tool set depends on the Desktop Bridge plugin. Before committing, verify that Node.js 18+ is available on the machine, that your MCP client is one the README lists, and that your Figma plan permits the personal access token you create. Then run the NPX setup and confirm the tool count your client reports matches the mode you chose.

## FAQ

### Is there an MCP plugin for Figma?

figma-console-mcp ships a Figma Desktop Bridge plugin in the figma-desktop-bridge/ directory of the repository, and the README lists it as a capability of the NPX, Local Git, and Cloud Mode setups. Remote SSE does not use the plugin.

### How to install figma-console-mcp?

The README recommends the NPX setup, which requires Node.js 18+, Figma Desktop, and an MCP client. You create a Figma personal access token, then configure your client to run the figma-console-mcp package, which exposes a binary of the same name.

### What is figma-console-mcp?

It is a Model Context Protocol server that connects AI assistants to Figma for design system extraction, creation, debugging, and bidirectional token sync. It is written in TypeScript and published under the MIT licence.

### How to use figma-console-mcp?

After setup, your MCP client gains Figma tools: reading variables, components, and styles, creating frames and component sets, managing variables, and syncing tokens in both directions. The README notes the NPX and Local Git setups expose 121 tools, Cloud Mode 101, and Remote SSE 9.

### How to set up figma-console-mcp?

The README lays out four paths: NPX or Local Git for the full 121-tool set with Figma Desktop, Cloud Mode for web AI clients without Node.js, and Remote SSE for read-only exploration with 9 tools. Each path starts with a Figma personal access token.

## Sources

- [License: MIT](https://github.com/southleft/figma-console-mcp/blob/main/LICENSE)
- [Project website](https://southleft.com)
- [README](https://github.com/southleft/figma-console-mcp/blob/main/README.md)
- [Releases](https://github.com/southleft/figma-console-mcp/releases)
- [southleft/figma-console-mcp on GitHub](https://github.com/southleft/figma-console-mcp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/southleft-figma-console-mcp