Figma MCP Bridge: a plugin-and-server pair that sidesteps the Figma REST API

The six-requests-a-month problem this project was built around

The README states the motivation directly: Figma limits free accounts to 6 API requests per month, and it links to an open issue on Figma-Context-MCP about that limiting. Any MCP server that reads a Figma file through the REST API spends one of those requests per call, so a single afternoon of prompting an agent can exhaust a free account's quota for the rest of the month. Figma MCP Bridge takes the plugin route instead. A Figma plugin runs inside the Figma desktop or web client with access to the open document, so it does not need the REST API to read node trees, styles, variables or selections. The MCP server is the other half: it exposes tools to the AI client and relays their results from the plugin. The target user is a designer or front-end engineer on a free Figma plan who wants an agent to read a design and produce code, and who is not willing to pay for an API quota just to let the agent look at a frame.

What the README says about the bridge, and what it leaves out

The README has a How it works section in its table of contents, but the cleaned text supplied here does not include its body, so the transport between plugin and server cannot be confirmed. What the material does establish is the shape of the data flow: open the plugin in a Figma file, the MCP server connects to it, and the AI tool then calls tools by name. Multiple files can be connected at once, one plugin instance per file, and each connection is addressed by fileKey. The tool list is the clearest evidence of what crosses the bridge. Read tools cover the document tree, the current selection, a single node by ID in colon format such as 4029:12345, local paint, text, effect and grid styles, file metadata, a depth-limited tree for design context, variable collections with their modes and values, and node exports as PNG, SVG, JPG or PDF in base64. Because the plugin runs inside Figma, none of those reads consume REST API requests. That is the whole architectural bet, and it is a reasonable one. The cost is that the bridge only works while a human has the file open and the plugin running.

Setup: one JSON block, one manifest import

Installation is two steps. First, add the server to the AI tool's MCP configuration, for example Cursor, Windsurf or Claude Desktop, using this block from the README: a figma-bridge entry whose command is npx and whose args are -y and @gethopp/figma-mcp-bridge. There is no binary to download. Second, download the plugin from the latest release page, then in Figma choose Plugins > Development > Import plugin from manifest and select the manifest.json file from the plugin/ folder. After that you open a Figma file, run the plugin, and prompt your AI tool; the README states the MCP server connects to the plugin automatically. The README does not give a port number, a hostname, an environment variable or a config key beyond the MCP command block, so if the automatic connection fails there is no documented knob to turn. The plugin is imported as a development plugin rather than published through Figma's plugin directory, which means it is not sandboxed by a review process and you are trusting the release artifact you downloaded.

The write tools are the part I would not hand to an agent yet

Alongside the read tools, the repository ships a set of write tools: set_text_content, set_text_properties, set_node_properties, set_solid_fill, set_gradient_fill, set_effects, set_stroke_properties, set_auto_layout, create_page, create_frame, create_text, create_shape, create_image, import_html_layers, duplicate_nodes, reparent_nodes, set_node_visibility, plus a beta group for motion: get_motion_styles, get_node_motion, apply_animation_style, remove_animation_style, apply_manual_keyframe_track, remove_manual_keyframe_track and set_timeline_duration. The README calls this a small, opt-in set, and points to an Editing Notes section for details. That section is not present in the material supplied here, so how the opt-in is expressed (an environment variable, a separate server entry, a flag) is unknown. The list is not small. It includes destructive operations such as reparent_nodes and remove_manual_keyframe_track, and creation operations such as create_page which the README says can optionally switch to the new page. An agent that misreads a prompt can restructure a file. Whether there is an undo boundary, a confirmation step or a dry-run mode is not stated in the material I have.

Multi-file support and the fileKey addressing model

The multi-file design is the most concrete differentiator in the documentation. Open the plugin in each Figma file and the bridge keeps all connections active; the agent then targets a file by fileKey using list_files to enumerate what is connected. Single-file setups need no changes, so the addressing model is additive rather than a different mode. This matters for teams where a design system lives in one file and the screens being implemented live in another: the agent can read tokens from the system file with get_variable_defs and read the screen from the product file in the same session. The constraint is that every file you want reachable must have the plugin running. Close the tab, and that fileKey presumably drops out of list_files, though the README does not describe the disconnect behaviour or whether a tool call against a closed file returns an error or hangs. For a single designer working on one file this is invisible. For an agent running unattended, it is the failure mode to test first.

Where this is the wrong tool

If you need design data without a browser or desktop client in the loop, this is the wrong choice. A CI job that reads a Figma file on a schedule, a nightly design-token sync, or any pipeline that runs when nobody has the file open cannot use a plugin-based bridge, because the plugin only exists while Figma is running and the file is loaded. You would need the REST API and a paid plan with a workable quota. The same applies if you want a stable, versioned interface: this project is at v0.0.21 with releases at roughly two-week intervals (v0.0.19 on 2026-08-10, v0.0.20 on 2026-08-26, v0.0.21 on 2026-09-01), and pre-1.0 version numbers signal that tool names and arguments can change. There is also a trust dimension: importing an unreviewed development plugin into Figma grants it access to the open document, and the README does not describe what the plugin does with that access beyond relaying it to the local MCP server. If your organisation restricts which plugins can run against client files, this project will not clear that bar without an internal review.

The alternative: Figma-Context-MCP and the REST API trade

The README names Figma-Context-MCP as the comparable project and links to its rate-limit issue. The difference in approach is straightforward. Figma-Context-MCP reads Figma through the REST API: it is a server you run, it needs a Figma API token, and it works whether or not anyone has the file open, which is why it fits automated pipelines. Figma MCP Bridge reads through a plugin running inside a live Figma session: no API token, no monthly request quota, but a hard dependency on an open file and a running plugin. The two are not competing on features so much as on where the data comes from. If your quota is the binding constraint and you work interactively, the bridge removes the constraint. If your constraint is that no human is present, the REST route is the only one that works, and the quota becomes a budget question rather than an architectural one. A team could reasonably run both: the bridge for interactive agent sessions, the REST server for scheduled jobs, accepting two configurations to maintain.

Licence, maintenance and what to verify before you commit

The project is MIT-licensed and written in TypeScript, so you can read the source, fork it, and ship modifications under the same terms. MIT imposes no copyleft obligation on your own code, but it also provides no warranty, and the README offers no support channel beyond the repository. The maintenance signal available here is release cadence: three releases in the three weeks before 2026-09-01, which suggests active work rather than a dormant repository, though a fast cadence at 0.0.x also means churn. Upgrading means re-running npx against a new version and re-importing the plugin manifest from the matching release, since the plugin and server are separate artifacts that must agree on their protocol. That pairing is the upgrade cost to plan for: if you pin the server version in your MCP config, pin the plugin release too, and test the pair together after each bump. Nothing in the material describes a compatibility matrix between plugin and server versions, so treat a mismatched pair as an untested configuration.

Editorial conclusion

Adopt Figma MCP Bridge if you are on a free Figma plan, you work in Cursor, Windsurf or Claude Desktop, and your workflow is read-heavy: pulling document trees, selections, styles and variable definitions into an agent. Do not adopt it if you need a documented network protocol, a stable API, or write access to shared production files, because the README does not specify the transport, the port, or how concurrent plugin sessions are isolated, and the write tools are described only as a small opt-in set. Before trusting it, verify three things yourself: which local port or socket the plugin and server agree on, what happens to in-flight tool calls when you close a Figma tab, and whether the write tools can be disabled entirely in the MCP configuration. The project is MIT-licensed and three weeks of releases separate v0.0.19 from v0.0.21, so pin the version you test.

Official sources

1. gethopp/figma-mcp-bridge on GitHub
2. Issues
3. License: MIT
4. README
5. Releases