title: "Figma 如何在快速迭代中推出 MCP Server"
source_url: "https://www.youtube.com/watch?v=ZIYYsAzaLlA"
author: "AI Engineer"
excerpt: "公共早报 Figma 工程师 Jesse Lumarie 讲述团队如何把早期 MCP 实验发展为本地与远程服务：让设计上下文真正服务于编程智能体，以务实评测检验输出，并在生态尚未成熟时守住安全边界。"
Brief Description
Jesse Lumarie describes how Figma built and launched its first MCP server while the protocol and client ecosystem were still changing. The talk covers the product's origin, choices around design-context serialization and evaluation, compatibility gaps in MCP clients, the local-to-remote rollout, and the principles that helped the team move quickly without compromising security or user trust.
Table of Contents
From an internal experiment to a Figma MCP product
Representing Figma design context for coding agents
Evaluating output quality and connecting designs to code
Working around incomplete MCP client support
Launching local and remote servers with security in mind
What Figma learned from the launch
From an internal experiment to a Figma MCP product
Jesse had been a software engineer at Figma for about three years when the team built Figma's first MCP server in roughly three months. The server lets AI tools exchange context between production code and design, so those tools do not each need a dedicated Figma integration.
Anthropic released the MCP server specification in November 2024, and people working with AI quickly began experimenting with it. At that point, adoption outside Anthropic was limited: OpenAI, Cursor, and VS Code had not yet implemented support. Once the team could use the feature in Cursor, they could explore its capabilities and see the beginnings of a product.
Jesse was working on growth initiatives and wanted the internal demo for non-designers who wanted to use Figma. A one-day-a-week side project became a Figma-plugin-based MCP server, then a staffed effort with other teammates. After the team had begun settling the architecture, a new version of the specification deprecated server events, which had been part of their plan. Meanwhile, clients were adding support at different speeds and with different feature sets. The uncertainty made it difficult to know exactly what they were building toward, but the team believed MCP would be powerful enough to justify moving ahead.
The first local MCP server was designed heavily around developer use cases. Developers were early adopters of AI workflows and could use a single prompt such as asking an agent to implement a design. The coding agent could pull the context it normally needed from Figma Dev Mode: component data, spacing, variables, and related information. The team continued adding read tools for Figma, FigJam, Make, and other surfaces with the shared goal of making Figma context available to developers wherever they worked.
Representing Figma design context for coding agents
Figma is a canvas represented as a scene graph in C++, a graph of connected nodes comparable in some ways to the HTML DOM. The team considered several ways to represent that graph to an AI agent. One internal representation resembled JSX or XML: it converted the scene graph into tags and passed them to the agent. It was abstract and sparse, but did not offer especially rigorous fidelity.
Another option was D2R, Figma's React-and-Tailwind representation. Figma already had a Sites product that could convert a scene graph into HTML. The team suspected this representation would work well because many models were trained on React- and Tailwind-like code. When output from Figma MCP is pasted into a simple MCP or HTTP server, it should be pixel perfect; Jesse encouraged users to file a bug if it is not.
The team also considered sending a plain image. In early 2025, agents were not strong at directly converting images into HTML, CSS, or other languages, so images were useful as additional context rather than the only representation. In practice, the system showed a Figma frame alongside React Tailwind code. Images in the scene graph were abstracted and placed at the top level. Passing Base64 image data directly into the code was a bad first attempt because it consumed the context window. Sending an image of the current node alongside code context produced better agent output than the image alone.
Evaluating output quality and connecting designs to code
The team needed a practical definition of better output. Their initial evaluations mixed quantitative and qualitative measures. Quantitatively, they asked whether the result used variables, applied the expected theme, and placed elements in the correct locations. Qualitatively, they asked whether it looked good and made good decisions despite incomplete information.
At first, the team spent around two hours grading an evaluation in a spreadsheet and decided not to repeat that manual process. They assembled toy repositories and later built a web application to make evaluation easier. A challenge was that while much open-source code exists, fewer open-source projects include the matching Figma files. The team either created their own examples or found other ways to automate the system. Their current evaluation runs hundreds of times each week, enabling engineers to test prompt changes with LLM judges and remove unnecessary human work from the loop.
Pixel-perfect translated code is only half the problem for an enterprise. A result that ignores battle-tested, accessible, and internationalized components is still inadequate. Figma already had Code Connect, which links design components to components in a codebase. The MCP server needed to use that connection so an agent would choose the correct component rather than merely recreating its appearance.
For example, an HTML representation of a button could look accurate while failing to use the codebase's primary button and its accessibility or internationalization properties. It could also consume too much context. Code Connect turns a large React Tailwind representation into a sparse reference that effectively says to use the matching button component. By connecting code to design, Figma can send a pointer to the relevant code component and give agents a higher-fidelity implementation with less context.
Working around incomplete MCP client support
Once the serialization syntax felt solid, the team examined what an MCP server could be. The specification contained useful pieces, but some features were not fully developed in clients, while other desired features did not yet exist. The client compatibility matrix from March 2025 showed that many clients implemented only a subset of the protocol and that much of the support was experimental.
Figma now exposes resources that help an agent understand how to use the server and related Figma help articles. Previously, the agent might receive that information with an error and have to make calls that consumed inference and reasoning just to diagnose the problem. Server instructions were technically in the specification, but no clients implemented them and the documentation did not emphasize them until Anthropic published a helpful blog post. Until support improved, Figma added instructions to individual tool calls to guide the LLM in using the server.
The team also wanted elicitation and sampling. Elicitation lets a server ask the user a question, accept the response, and return it to the server. Sampling lets a server query the client's LLM; the canonical use case was small queries. Figma wanted to combine the two: ask a user for permission to map their codebase for Code Connect, then use the agent to find possible matches. This could improve output and reduce the design context sent to the model.
Most clients did not implement these features, and even VS Code's sampling support could query only a general agent rather than an agent with codebase-specific context. Figma worked around the limitation with tools. When an agent received context for a Figma design and Figma detected an unconnected component, it sent a prompt asking whether the user wanted to map the component. If the user agreed, it prompted the agent to scan the code for potential matches, asked for results in a specified format, and accepted them in bulk to create Code Connect mappings. Jesse also recommended the open-source MCP Inspector for people developing MCP servers.
The team wanted another signal about output quality because it could not know in advance whether React Tailwind would work across every kind of codebase. Elicitation and sampling did not work as well as hoped, so the tools accepted optional query arguments, such as the user's programming language or framework. Agents can provide imperfect information, but it was still useful for identifying user types that might be having a poor experience, perhaps because the translation layer was not working well.
Launching local and remote servers with security in mind
As the first beta approached, the team wanted four things: a quick launch, the highest possible security bar, respect for file permissions, and pricing and packaging that did not create abuse vectors. After the specification changed and introduced OAuth in March 2025, they had to decide whether to keep the MCP server local or switch to a remote server using streamable HTTP and solve the associated authentication problems.
They initially deferred the remote decision because there was not yet a stable specification to build on, and the web application could relay easily to the desktop application. Figma's desktop application is Electron: its front end is a web application running figma.com, with an IPC bridge to a Node process that can access the user's file system. The team exposed a server-events server in Node so clients could talk directly to it locally.
The local approach also appealed to enterprise customers because their data was not being sent elsewhere. It was the fastest way to get the product into users' hands, assess product-market fit, and learn which tools and use cases mattered. Figma launched the local server internally, received very candid feedback, fixed many problems, and began receiving positive community feedback. That launch was only the beginning; the team immediately began work on the remote server.
Clients were still progressing on different timelines, but Figma knew it wanted to ship the remote server. It launched in September, made both servers generally available in October 2025, and then added read and write capabilities. Together, those additions made Figma one of the company's fastest-growing products, an outcome the team had not expected when it began.
What Figma learned from the launch
Later, Jesse began working on another related effort after research showed that designers wanted to write production code in some cases and Figma did not have a dedicated product for it. Work with other MCP practitioners at an offsite became Make in the local codebase, Figma's agent solution for working with GitHub and local codebases.
Jesse's main takeaway is that the field is still early. The MCP specification is only two years old, and teams are still discovering the best ways to work with it. Figma's experience also reflects the value of giving engineers room to build and investigate what comes next. Jesse was not originally staffed on MCP or on Make, but was able to contribute because of that latitude and learned a great deal along the way.