Platform integration
Agent infrastructure
Figma MCP exposes design data to AI agents through the Model Context Protocol. Here's what the server does, what it doesn't, and what the pattern means.
When a developer asks Claude to "build the settings page from our Figma file," what actually happens? Until recently, the answer was: nothing useful. The agent couldn't read the file, couldn't inspect the components, couldn't pull the design tokens. Now, with Figma's Model Context Protocol server, it can.
Figma MCP is one of the first design-tool integrations of the Model Context Protocol (MCP) to ship from a major vendor, and it's worth looking at carefully. Not because design-to-code is the most important agent use case, but because Figma's approach reveals what MCP does well, what it doesn't solve, and what design tool MCP integration tells us about the wider tools layer.
This piece walks through five things: what Figma's MCP server actually exposes, how the protocol fits the design-to-code workflow, where the model behind the agent still struggles, the limits of a vendor-built MCP server, and what the pattern means for any SaaS company watching this space.
Figma's Dev Mode MCP server entered beta in mid-2025. The original beta ran locally alongside the Figma desktop app; Figma added a remote MCP server in September 2025 that an agent can connect to without the desktop client. An agent — Claude in Anthropic's Claude Code, Cursor, or any MCP-compatible client — connects to it and gets a defined set of tools.
The tools cluster around a single workflow: turning a selected frame or component into something a developer can implement. The agent can fetch the structured representation of a node, pull out the variables and styles attached to it, retrieve image assets, and walk component hierarchies. On the metadata side, it can read component descriptions, variant properties, and the design tokens a team has defined in Figma's variables system.
At beta launch, the server was read-only — no tool for editing files, creating components, moving objects on the canvas, or posting comments. Figma has since added write capabilities (notably use_figma, which executes Plugin API code to create and modify Figma objects, and a code-to-canvas generation path), available to paid Full and Dev seats. Even with those additions, the surface still concentrates on the design-to-code handoff and leaves most of the product — comments, file management, team admin, and so on — untouched. Figma made a choice about which slice of the product to expose first, and that choice prioritises the design-to-code handoff over every other workflow a Figma user might want an agent to touch.
This is a pattern. Vendor-built MCP servers tend to expose the workflow the vendor is most confident about — the one with the clearest agent demo and the lowest support surface. It's a sensible product decision. It's also a hard ceiling for anyone who needs more than that one workflow.
MCP, as a protocol, is a good fit for the read-and-summarise pattern that design-to-code requires. The agent selects a node, the server returns structured data about that node, the agent reasons over the data and writes code. The protocol is doing the boring, valuable work: standardising how the tool is described, how it's called, how the result comes back, and how the server identifies itself to the client.
Before MCP, getting Figma data into an agent meant one of two things. Either you used the Figma REST API directly, which requires API tokens, request construction, and your own logic for walking the document tree — none of which the agent does well unsupervised — or you used a custom Figma plugin that exported JSON to disk and asked the agent to read the file. Both work. Neither is reusable across agent frameworks, models, or clients.
MCP collapses that. The Figma server publishes its tool definitions in a standard shape. Claude, Cursor, or any compliant client picks them up automatically. The same server works with whichever model the developer prefers today and whichever they switch to tomorrow. That's the real win — not the specific tools, but the fact that the integration travels.
For the design-to-code use case specifically, MCP also gives the agent something it didn't have before: a way to ask narrower, structured questions. Instead of dumping a whole Figma frame as JSON and hoping the model picks out the right variable names, the agent can call get_variable_defs against a specific node and get back exactly the tokens that frame uses. The model's context window gets used for reasoning instead of for parsing.
Figma MCP makes the data reachable. It doesn't fix every failure mode in design-to-code generation, and a fair piece on this category has to be honest about that.
Three problems persist. First, design intent doesn't fully serialise. A frame in Figma carries visual information — the way components nest, the way spacing implies grouping, the way colour signals state — that the structured representation flattens. The agent gets the data, but the data isn't the design. Components named "Frame 247" or styled without variables give the model nothing to grip onto. Teams with disciplined component systems and named variables get dramatically better output than teams without. Figma's MCP server doesn't change that; it inherits it.
Second, the output target matters more than the input quality. Generating a React component with Tailwind and the team's specific design-system primitives is a different problem from generating raw HTML and CSS. The MCP server tells the agent what the design says. It doesn't tell the agent what the codebase expects. That's a job for additional tools — usually a second MCP server pointed at the repo, or rules and context files in the IDE — and getting the two to play together is still mostly manual.
Third, iterative refinement is weak. Design-to-code in practice is rarely a single shot. The developer wants the component, then wants to adjust spacing, then wants to swap the colour token, then realises a variant is missing. Each round means re-selecting in Figma, re-prompting the agent, and hoping the agent's earlier work stays consistent. Nothing in the protocol prevents this loop from working well; nothing yet makes it work well, either.
Figma MCP is a real step. It's not a finished product.
When the vendor ships the MCP server, you get authority — the people who built the product define the tools — and you get a hard scope. The Figma server exposes what Figma chose to expose, on Figma's timeline, with Figma's auth model, against Figma's view of which workflows matter.
For most teams, that's fine until it isn't. A design system team that wants an agent to audit token usage across files needs tools the server doesn't have. A QA team that wants an agent to flag accessibility issues against a component spec needs reasoning the server doesn't support. A frontend team that wants deep two-way sync — the agent updating Figma components in lockstep with code changes — is still waiting on a roadmap they don't control, even with the new write tools in place.
The pattern repeats across every major SaaS product shipping an MCP server. GitHub's MCP server is excellent for repository operations and modest for actions. In our experience, Linear's server covers issues, projects, cycles, and documents well, while initiatives, roadmaps, and most of the admin surface stay outside its reach. Notion's server centres on pages, databases, and search, with comment and user tools alongside — but large swathes of the product (automations, teamspaces admin, integrations management) sit outside it. None of these are bad servers. They're scoped servers, scoped by the vendor.
This is the same structural problem the Pontil team has written about before: the UI does ten things, the API exposes two, and the MCP server — which has to be built against the API — inherits the gap. A vendor MCP server is an interface to the vendor's existing API surface, dressed in protocol clothes. It doesn't conjure new capability.
If you ship a SaaS product and you're watching Figma's MCP server land, the lesson isn't "build one of these." It's "understand what shipping one would require."
A useful design tool MCP integration requires three things: an API surface that covers the workflow you want the agent to touch, a tool layer above that API surface that's shaped for agent reasoning rather than for developer integration, and a runtime that handles auth, rate limiting, and observability under agent-driven load patterns that don't look like human traffic. Figma had a strong starting position on the first — Dev Mode and the Figma REST API have been mature for years — and still chose to ship a narrow first version.
Most SaaS companies don't have Figma's starting position. The APIs cover a fraction of the product. The auth model was built for OAuth-via-browser flows, not for agent runtime calls executing as the authenticated user. The observability stack assumes human-rate traffic. Building an MCP server in this state isn't a weekend project — it's a multi-quarter rewrite of the API layer that the original agent project stall was about.
The alternative most teams reach for first — write bespoke connectors for each product, each agent use case, each customer — runs into a different wall, mapped in the hidden cost piece. Bespoke doesn't compound. Every product the company ships needs its own connector. Every API change breaks something. Every new agent client adds glue. The team that started by saying "let's just build one" ends up running an internal integration platform they didn't budget for.
Figma can ship a single MCP server because Figma is one product. A SaaS company with seven products has seven of these problems, all on different stacks, all with different APIs, all moving at different speeds.
The Figma example sits at one end of the spectrum: a single mature product, a strong API, a narrowly scoped MCP server shipped by the vendor. Pontil exists for the other end — established B2B SaaS companies with multiple products, where rewriting every API to MCP-server-readiness isn't a quarter of work, it's years of it.
Pontil is a Tools-as-a-Service platform. We generate the tool layer from the codebase you already have, run it as the authenticated user, and keep it current as the product changes. The protocol the agent speaks — MCP today, something else tomorrow — sits on top of that. It's a presentation detail, not the substrate.
What that means for teams looking at Figma MCP and wondering when the same will exist for their products: the answer probably isn't "when we ship an MCP server." It's earlier, when the tool layer covers the workflows agents actually need. You can see how the runtime works in a demo when that's a useful next step.
The interesting question isn't whether more design tools will ship MCP servers — they will. Sketch, Framer, and Penpot all have the shape to support one. The interesting question is whether the next wave of design tool MCP integrations gets broader than the design-to-code handoff that Figma led with.
My guess: slowly. Vendor-built servers grow at the speed of vendor roadmaps, and the roadmap pressure is on getting the first workflow to work well across enough clients to be worth supporting. The second workflow — design-system audits, accessibility reviews, content updates from agents writing copy — will arrive, but not on the timeline most agent teams are working to. Teams that need those workflows in the next two quarters will end up building their own tools against the underlying APIs, accepting the maintenance burden, or finding a tools layer that lets them define the surface themselves.
The Figma MCP launch is a useful proof point that the protocol works and that vendors are willing to ship against it. It's not a sign that the access problem is solved. For most SaaS companies — and for most teams trying to make agents useful against design tools beyond the obvious workflow — the work is still ahead.
Stay up to date on the ever changing agentic landscape.
