Back to projects
From Figma selection and MCP tool calls to the resulting Flutter screen

In use · Public

Figma MCP Bridge

A bridge that turns a selected Figma node into implementation-ready context for AI code editors.

A three-person OSS bridge that sends selected Figma nodes to AI code editors without requiring an extra Dev Seat. I contributed to architecture discussion and MCP server work, and owned Codex integration research, setup commits, and Korean/English/Japanese documentation. I did not build the plugin body or entire bridge alone.

Period
2026.04 - 2026.06
Ownership
Architecture discussion · MCP server contribution · Codex docs
Team
3-person team
Repository
Public repository

Links

GitHub (OSS)Blueberry Team

A low-cost design handoff the whole team could use

AI code editors did not improve team productivity if every developer still had to describe Figma colors, spacing, text, and hierarchy by hand. Providing a paid Dev Seat for every contributor was also impractical.

We therefore decided to build a team tool that sends the element currently selected in Figma directly to an AI code editor through the same repeatable workflow.

The design bridge

Only the selected design returns to the code editor

  1. 01

    AI code editor

    Claude Code / Windsurf / Codex

  2. 02

    MCP server

    Input checks and response shaping

  3. 03

    Connection bridge

    Relays between editor and Figma

  4. 04

    Figma plugin

    Reads the current selection

  5. 05

    Selected design

    Color, spacing, text, and hierarchy

Narrowing AI context to the selected Figma node

Even when implementing one button, fetching the full Figma file through the REST API included unrelated pages and nodes in the response.

The tool needed to work without an extra paid Dev Seat for every teammate and return only implementation-relevant information from the selected node. Reproducing the REST API's large response through another path would not solve the problem.

The team chose the Desktop Plugin API to read the current selection and return implementation context through the MCP server and WebSocket bridge. I contributed to that design discussion, server-side work, and client validation.

  • Contributed to MCP server tool implementation and validation.
  • Verified `figma_get_node` and `figma_get_selection` in Codex.
  • Recorded reproducible setup in Korean, English, and Japanese READMEs and config files.

In one sampled node, the REST response was 2,307 lines and 142 KB. The public bridge was used in Umaso and Lingding, but we did not measure time or token use against the official Dev Seat.

Selecting context for the current task was more useful than sending as much information as possible.

Figma MCP Bridge running screen

Different failures should point to different next actions

An MCP request crosses stdio, WebSocket, and the Figma plugin. If every failure became an empty response or generic error, users could not tell whether to fix setup, connection, or selection.

Claude Code, Windsurf, and Codex use different MCP registration and runtime setups. User-correctable states such as Figma not running, no selection, and multiple client connections also needed to remain distinguishable.

The team implementation kept disconnected, empty-selection, and multi-client states distinct. I reproduced real calls in each client and documented Codex setup and verification steps in the README.

  • Reviewed server-to-plugin failure categories with the team.
  • Reproduced registration and tool calls in Claude Code, Windsurf, and Codex.
  • Documented global versus project Codex setup.

I verified real tool calls in Claude Code, Windsurf, and Codex and recorded reproducible steps in the public README. Automated tests for connection-failure scenarios are not yet in place.

I learned that an integration tool needs failure contracts that guide the user's next action, not only a successful response.

The OSS repository is public. We validated the team bridge across three clients; my publicly traceable work includes Codex setup and multilingual documentation commits. We also used it during Umaso and Lingding screen work.

When building AI tooling, I now name one task to shorten—for example, implementing a selected Figma button—before choosing the data path. I then send only the node, layout, text, color, and spacing needed for that task and return errors that let the client distinguish why the call failed.

There is no measured result proving technical superiority over Dev Seat or a quantified multiplier for implementation speed.

  • Compare Curl, the bridge, and official MCP under the same task
  • Add tests for disconnects, Figma not running, and no selection
  • Create a safe public Figma sample