Figma MCP Bridge: a plugin plus MCP server that sidesteps Figma API rate limits

The 6-requests-per-month problem the bridge was built around

The README is blunt about the motivation. It points at another Figma MCP server, Figma-Context-MCP, and at a linked issue about API limiting for free users, then states the number: the limit for free accounts is 6 requests per month. That is the whole argument for this project. A server that reads a Figma file through the official API spends a request every time an agent asks for the document tree, a node, or a screenshot. Six of those per month is not a workflow, it is a demo.

Figma MCP Bridge moves the read path off the REST API. A Figma plugin runs inside the document, where the plugin sandbox already has access to the current page, the selection, local styles, and variables. The plugin streams that data to a local MCP server, and the MCP server exposes it to the AI tool as tools. No API quota is consumed because no API call is made.

The audience follows from that. It is for people doing design-to-code work on a free Figma plan, and for anyone who wants an agent to read a design without counting requests. It is not a hosted service and it is not a Figma feature. It is two pieces you install yourself: an npm package for the server and a plugin folder you import into Figma.

Two halves, one local connection, many files

The repository is split at the top level into plugin/ and server/, which matches the two halves described in the README. The server is published as @gethopp/figma-mcp-bridge and is started by the AI tool through npx. The plugin is a Figma plugin that you import from its manifest. The README says the MCP server will automatically connect to the plugin once the plugin is running in a file, so the transport is local and needs no configuration beyond starting both sides.

Multi-file support is the part worth understanding. The README states that you open the plugin in each Figma file, the bridge keeps all connections active, and the agent can target any of them by fileKey. The list_files tool exists for exactly this: it enumerates the connected files so the agent knows which keys are available. Single-file setups work with no changes, which means an agent that never calls list_files still behaves as before.

The tool surface is large and split between reads and writes. Reads include get_document, get_selection, get_node (node IDs use colon format, for example 4029:12345), get_styles, get_metadata, get_design_context, get_variable_defs, and get_screenshot. get_design_context is described as a depth-limited tree optimized for understanding design context, which matters because a full document tree can be far more than a model wants to read. Writes are grouped under an opt-in set and cover node properties, text, fills, gradients, effects, strokes, auto-layout, page and frame creation, duplication, and reparenting. A separate beta group covers motion: animation presets, keyframe tracks, and timeline duration.

Installing the MCP server and importing the plugin

The server goes into your AI tool's MCP configuration. The README gives this exact block for Cursor, Windsurf, or Claude Desktop, and notes there are no binaries to download. The command is npx with the -y flag and the package name; the key figma-bridge is the name your AI tool will show.

{
  "figma-bridge": {
    "command": "npx",
    "args": ["-y", "@gethopp/figma-mcp-bridge"]
  }
}

After saving that config and restarting the AI tool, the MCP server should appear in the tool's MCP list. It will sit idle until a plugin connects, so do not expect tools to return data yet.

The plugin is not installed from npm. The README says to download it from the latest release page, then in Figma go to Plugins > Development > Import plugin from manifest and select the manifest.json file from the plugin/ folder. The release artifacts are where the built plugin lives; the repository's plugin/ directory is the source layout. Once imported, the plugin appears under Development in the Figma plugin menu for that user.

The first real use is short. Open a Figma file, run the plugin, and prompt your AI tool. A reasonable first prompt asks the agent to list the connected files, then to read the current selection. If the agent returns a fileKey and node data, the bridge is working. For a second file, run the plugin there too and ask the agent to list files again; the README states both connections stay active.

Where the plugin architecture costs you

The trade-off is explicit in the design. Bypassing the REST API means the data comes from a plugin session, and a plugin session only exists while someone has that file open with the plugin running. Close the file, or forget to run the plugin, and the bridge has nothing to serve. A REST-based server can read a file from a URL with no human present; this one cannot. The README does not document a headless mode or a way to keep a file connected without the plugin, so treat the live session as a hard requirement.

The second constraint is scope. The plugin reads what the plugin can reach: the current page, the selection, local styles, and variables. The tool list reflects that. There is no tool for reading a different page than the one the plugin is on, and get_document is described as the current Figma page document tree, not the whole file. get_metadata returns the file name, pages, and current page info, so an agent can learn which pages exist, but switching pages is not in the documented tool set.

The third is the write surface. The README calls the write tools a small, opt-in set for safe agent-driven edits, and lists operations that change fills, text, layout, and node structure. Opt-in is a configuration stance, not a sandbox. If you point an agent at a working file with write tools enabled, the agent can change that file. The README does not document an undo mechanism, a dry-run mode, or a confirmation step, so the practical safeguard is Figma's own version history and the fact that you chose to enable the tools.

How it differs from Figma-Context-MCP and the REST route

The README names Figma-Context-MCP directly and frames the difference as one of transport. Figma-Context-MCP reads Figma through the API, which is why the rate limit applies and why the linked issue exists. Figma MCP Bridge reads through a plugin, which is why the limit does not apply and why a live session is required. Neither approach is strictly better; they fail in opposite directions. The API route fails when you run out of requests. The plugin route fails when nobody has the file open.

There is a second difference in what can be read. An API-based server works from a file key and can be pointed at files the user has not opened in the desktop or browser client. A plugin-based server sees the document as the plugin sees it, including the current selection, which is genuinely useful for prompts like "describe what I have selected" and is awkward to express through a REST call. The selection tools here, get_selection and get_node, are a direct product of that.

The multi-file behavior is a third point of contrast. The README states the bridge supports multiple Figma files connected simultaneously and that the agent queries them by fileKey. That is a different model from a server that takes a URL per request. It also means the set of readable files is the set of files where someone ran the plugin, which is a smaller and more deliberate set.

Licence, release cadence, and what maintenance costs you

The project is MIT licensed, with the licence file at LICENSE.md. For adopters that means the usual MIT permissions and the usual absence of warranty, and it means you can vendor or fork the plugin and server if you need to. It does not tell you anything about whether the maintainers will keep publishing. Nothing here is legal advice; read LICENSE.md for the actual terms.

The repository's root package.json is private and contains only formatting tooling: husky, lint-staged, and prettier, with prepare, format, and format:check scripts. It is not the published package and it carries no version of its own, so do not read it as a release manifest. The published npm package is @gethopp/figma-mcp-bridge, and the plugin ships through GitHub releases.

Upgrade cost is low on the server side and manual on the plugin side. The MCP config uses npx with -y, so the tool fetches the package when it runs and a restart picks up a newer version. The plugin is imported from a manifest, so a new plugin build means downloading the release and importing it again. The release history shows v0.0.21 on 2026-09-01, v0.0.20 on 2026-08-26, and v0.0.19 on 2026-08-10, and the last push to the default branch was on 2026-09-01. Version numbers still in the 0.0.x range are a fair signal that the tool list can change between releases; the beta motion tools in particular are labeled beta in the README.

Editorial conclusion

Adopt Figma MCP Bridge if you are on a free Figma plan, or if you need an agent to read from several Figma files at once, since the README states the plugin can be opened in each file and the agent targets one by fileKey. Do not adopt it if you want a single process that reads public Figma URLs with no plugin running, because the bridge depends on a live plugin session for every file it serves. Before wiring it into a daily workflow, verify that the write tools are acceptable for your files, since the README groups them under an opt-in set for agent-driven edits, and confirm the plugin manifest loads in your Figma build by importing plugin/manifest.json through Plugins > Development > Import plugin from manifest.

Frequently asked questions

Official sources

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