figma-console-mcp: an MCP server that treats your Figma file as a readable, writable API
Your design system as an API. Connect AI to Figma for extraction, creation, and debugging.
At a glance
- What is it?
- The project wraps the Figma plugin and REST surfaces behind 121 MCP tools, adds a codebase-to-design-system extraction pipeline in v1.40.0, and ships a read-only remote mode with nine tools. The interesting part is the capability split between its four connection methods, and that split is where most adoption mistakes will happen.
- Who is it for?
- Adopt it if your team lives in Figma Desktop, already runs an MCP client such as Claude Code or Cursor, and wants write access to variables and components rather than a read-only dump. Do not adopt it if you only need to read design data, since Remote SSE covers that with nine tools and no Node.js, or if you cannot install Figma Desktop, because the Desktop Bridge plugin is where real-time monitoring and much of the write path live.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap it fills: Figma has an API, but not an agent-shaped one
Figma exposes a REST API and a plugin runtime, and neither is convenient for a language model to drive. The REST side is read-oriented and token-authenticated; the plugin side can write, but only from inside the desktop app and only through code you author and load yourself. figma-console-mcp exists to sit between those two surfaces and an MCP client, presenting Figma as a set of callable tools. The README frames the goal as "Your design system as an API," and the tool inventory backs that up: variable management, component creation, token export and import, screenshots, accessibility scanning, FigJam boards, Slides decks, and version history diffs. The audience is narrow and specific. It is designers and design engineers who already use an MCP-capable assistant and want that assistant to touch real design files rather than paste JSON into a chat window. If your workflow is Figma in a browser tab and no local Node.js, only part of this project is available to you.
Four connection modes, and the tool count that separates them
This is the part of the README worth reading twice. The project documents four ways to connect, and they are not equivalent. Remote SSE is read-only with 9 tools and no Node.js requirement, which the README describes as suitable for exploring design data in about two minutes. Cloud Mode reaches 101 tools and is aimed at web AI clients such as Claude.ai, v0, Replit and Lovable, routing writes through a Cloud Write Relay with cloud pairing. NPX and Local Git both reach the full 121 tools and add real-time monitoring of console logs and selection, which Cloud Mode does not have. The README's own summary line states the split plainly: Remote SSE is read-only with 9 tools, Cloud Mode unlocks write access with 101 tools, and NPX or Local Git gives the full 121. Two constraints follow. First, real-time monitoring is exclusive to the local modes, so an agent that needs to react to what a designer is currently selecting cannot be built on Cloud Mode. Second, the Desktop Bridge plugin is listed as available in NPX, Local Git and Cloud Mode but not Remote SSE, which means the plugin is the write path and the remote mode is genuinely a viewer. Treat the mode choice as an architecture decision, not an installation preference.
The v1.40.0 extraction pipeline: codebase in, DTCG tokens out
Release v1.40.0, dated 2026-08-16 and titled Design System Extraction, adds seven figma_ds_* tools that run in Local Mode and point the flow in the opposite direction from the rest of the server. Instead of reading Figma, they scan one or more application codebases. The README lists what the scan produces: framework, styling-method and vendor-layer detection; a component inventory ranked by usage and 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, with the README's own example being that a FollowButton is really a Button plus missing generic primitives. From there the tools mine the app's de-facto styling into DTCG tokens with per-token provenance, covering multi-mode CSS custom properties such as .dark and [data-theme], SCSS variables, Tailwind config values, shadcn HSL triples, Tailwind utility-class frequency mining valued against the app's own theme, and frequency-promoted raw values. The output includes a scaffolded design-system package with token, typography and iconography showcase pages, a Storybook workshop wired to the app's real theme layers and fonts, CSF3 story scaffolds for deep-extracted components, deterministic fidelity evals as a gate, and persisted porting progress across sessions. The claim that matters for integration is that the extracted tokens/tokens.json imports into Figma variables through figma_import_tokens, which the README describes as a full code to design system to Figma round-trip. This is server-only and needs no plugin re-import. The same release also fixes token formatters quoting CSS functional expressions such as cubic-bezier(...), which the README notes would silently kill transitions and affects figma_export_tokens output as well.
Getting it running: NPX, a Figma token, and the Desktop Bridge plugin
The recommended path is NPX, documented as roughly ten minutes, and it has three prerequisites the README states directly: Node.js 18 or later, checked with node --version; Figma Desktop rather than the web app; and an MCP client such as Claude Code, Cursor, Windsurf or Claude Desktop. You create a Figma personal access token from Figma's Manage personal access tokens help page, with the README suggesting the description Figma Console MCP. The README text supplied here is truncated partway through that step, so the exact client configuration block for each MCP client is not visible in the material I have. What is visible is the shape of the decision: pick NPX for full write access and monitoring, Cloud Mode for web clients without Node.js, Local Git if you are contributing to the project, and Remote SSE for read-only exploration. The package is published to npm as figma-console-mcp, and documentation lives at docs.figma-console-mcp.southleft.com. If you intend to use the v1.40.0 extraction tools, note the README's own qualifier that they are Local Mode only, so a Cloud Mode or Remote SSE setup will not expose them.
Where it breaks down or is simply the wrong tool
The clearest limitation is structural rather than a bug: capability is a function of connection mode. Anyone who reads the headline tool count and then configures Remote SSE will find nine tools and no write path, and the README does warn about this in a capability table, but the warning is easy to miss if you arrive at the quick start table and stop there. A second constraint is the Figma Desktop requirement for the full local setup. Teams standardized on browser-only Figma access, or on locked-down machines where desktop installs are not permitted, cannot use the modes that include monitoring and the Desktop Bridge plugin. Third, the v1.40.0 extraction pipeline is a substantial piece of machinery: codebase scanning, variant inference, frequency mining, Storybook wiring and fidelity evals. The README presents it as a single release feature, but the surface area suggests real setup effort and real judgement about which mined values are worth promoting to tokens. Frequency-promoted raw values in particular are a heuristic, and the README offers no accuracy figure, so treat the eval gate as the thing you must actually run rather than a formality. Finally, the accessibility scanning is described as 14 WCAG design checks with conformance level tagging, component scorecards, axe-core code scanning and design-to-code parity. That is a design-time check, not a substitute for testing rendered output with assistive technology, and the README does not claim otherwise.
Alternatives and the actual difference in approach
The README names two tools it intends to replace for token work: Style Dictionary and Tokens Studio's export pipeline. The difference is directional. Style Dictionary takes a token source file and generates platform outputs such as CSS, iOS and Android artifacts; it is a build-time compiler that does not talk to Figma at all. Tokens Studio lives inside Figma as a plugin and manages tokens there, with export as an output step. figma-console-mcp sits outside both: it drives Figma through an MCP client, exports variables to DTCG JSON in either a legacy or a 2025.10 dialect plus nine more formats, and pushes code-side edits back with creates, renames, alias re-targeting and replace-gated deletes. The distinguishing capability is that the same server also creates and edits design content, runs accessibility checks and reads version history, so token sync is one tool family among many rather than the product. If all you need is a deterministic token compiler in CI with no Figma round-trip, Style Dictionary remains the simpler dependency. If you need an agent to both read a Figma file and write back to it, the alternative is assembling the Figma REST API and a custom plugin yourself, which is the work this project has already done.
Maintenance, licence and the cost of staying current
The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it is worth noting that the README links a GitHub Sponsors page for southleft, so funding is voluntary rather than a licence obligation. This is not legal advice; if you vendor the code or ship it inside a product, have your own counsel confirm the notice requirements. On maintenance, the release cadence visible in the supplied material is active: v1.39.0 added concurrent multi-file execution, v1.39.1 fixed a plugin update banner, and v1.40.0 landed two weeks later with the design system extraction feature set, with the last repository push dated 2026-09-09. The upgrade cost is concentrated in two places. The four connection modes mean a server upgrade can change which tools your client sees, so a pinned NPX version is worth considering for teams that depend on a specific tool count. And the v1.40.0 formatter fix for quoted CSS functional expressions changes figma_export_tokens output, so any pipeline that diffs exported token files will show a one-time change on upgrade.
Editorial conclusion
Adopt it if your team lives in Figma Desktop, already runs an MCP client such as Claude Code or Cursor, and wants write access to variables and components rather than a read-only dump. Do not adopt it if you only need to read design data, since Remote SSE covers that with nine tools and no Node.js, or if you cannot install Figma Desktop, because the Desktop Bridge plugin is where real-time monitoring and much of the write path live. Before committing, verify three things in your own environment: that your Figma personal access token is accepted by the mode you picked, that the 121-tool count matches what your client actually lists after connection, and that the v1.40.0 extraction output at tokens/tokens.json round-trips through figma_import_tokens without losing your existing variable aliases.
Community notes