Figma announced that AI agents can write directly to the canvas through MCP. An agent can create components, apply variables, and edit frames using the design system already present in a project. Claude Code, Codex, Copilot, Cursor, and other clients can participate through the open protocol.
The associated skills are Markdown files that describe how an agent should behave inside Figma. A team can express naming, component, token, and composition rules without writing a plugin. The quality of the output therefore depends less on a generic prompt and more on the structure of the library and the clarity of those instructions.
This changes handoff because the Figma file becomes a shared work surface. A developer can ask for a settings flow and receive editable frames built from known assets. Design can inspect and revise the same artifact. The agent reduces transcription, while humans still decide which states, behaviors, and exceptions belong in the product.
Without a library the agent draws outside the system
use_figma works with components and variables already in the file. If the library is a pile of loose frames, the agent builds more loose frames. If there are color, spacing, and type tokens and components with auto layout, the output has somewhere to land. Figma puts this without ceremony: design-system context is what separates a generic screen from a brand screen.
Code Connect and variable syntax in Dev Mode make the same point from the other side. An agent generating code from a frame needs the mapping. An agent generating a frame from a request needs the library. Both sides thin produce UI nobody wants to maintain.
Before turning MCP on for the whole team, do a short inventory: which components cover the flows people ask for most, which variants actually exist, which variables the file uses, what is still loose text pretending to be a token. A hole in the inventory becomes rework, not "model creativity".
Teams without a design system can use the agent to bootstrap. The risk is publishing the bootstrap as if it were a system. Treat the first batch as a draft for humans to name, trim, and connect to code.
Skills describe the ritual; review closes the file
A skill is Markdown. Anyone on the team can write one. That lowers the barrier and spreads informal rules. Without an owner, each squad sends the agent down a different /figma-generate-design, with conflicting names. The file becomes a field of variants the DS does not recognize.
The base skill /figma-use teaches the agent to move around the canvas. The others (generate a library from code, generate a screen from components, apply spacing, sync tokens) are flows. The team chooses which ones enter the skills repo and who approves a change. Same care as a linter: a rule without maintenance becomes noise.
Screenshot self-checks help the model iterate. They do not replace review. Hierarchical spacing might even look acceptable; empty, error, permission, i18n, and real content almost never land right on the first pass. Design looks at the file. Accessibility looks at layer names and contrast. Product looks at whether that flow exists.
The skill can tell the agent to stop after N frames and list what it invented. That report is more useful than a crowded file. Invention without a list is debt.
Write permission on the canvas in this beta
Figma said: beta, free now, usage-priced later. MCP inherits account security. Even so, an agent with use_figma writes to the file the team treats as source. Without control over who connects the client (Claude Code, Codex, Copilot, Cursor, Warp), the canvas gains authors who never show up in critique.
Define a file or a sandbox page for the agent. Production DS (published library, team library) stays read-only until the flow proves the agent reuses components instead of duplicating them. Duplication is the expensive defect: the system loses adoption and the code loses mapping.
Usage pricing changes the bill when beta ends. While it is free, habit forms faster than sandbox discipline. A team that lets the agent write in every file will have to unlearn that when the price arrives. Better to already have the sandbox page and an allowlist of MCP clients.
Parity with the Plugin API is still an unfinished goal. Image and custom font support are on the expansion list. Flows that depend on those today fail in an opaque way. Do not promise design that "the agent does what the plugin does".
The shared frame changes the handoff
Classic handoff: design closes, engineering implements, the file ages. With an agent on both sides, engineering asks for a settings flow and gets editable frames in the same file design already works in. That cuts transcription. It also mixes authorship. Without a page convention ("agent / human / ready for build"), nobody knows what is stable.
A minimum convention: a page or section with a prefix, status in the frame name, and a rule not to publish the library from what the agent generated that day. Design reviews, promotes, then the component enters the system. The agent can keep editing the draft.
Time saved shows up on screens the system already covers: settings, lists, forms, a standard empty state. It disappears on a novel flow, marketing, illustration, motion. There the open canvas still helps exploration, but the ready bar stays human and slow, as it should.
Stitch and isolated generators produce UI outside the file. Here the artifact is born where the team already debates. That is the operational difference. It only holds if the team actually opens the file afterwards, instead of merging the frame into the product without design.
What to leave out of the first week of use
In the first week, do not ask for a rebrand, do not ask for 72 button variants on top of the published library, do not ask the agent to "align the whole app to the DS". Ask for a known flow, in a sandbox file, with the skill that generates design from existing components. Measure: how many components it reused, how many it created, how much design rewrote, how long until critique.
If the rewrite rate is high, the problem is the library or the skill, not the model. Adjust tokens, names, composition rules. Only then open it to more people. Opening early to the whole team, with MCP on in production files, creates volume nobody reviews.
Accessibility is not a bonus. There is a community skill for screen-reader specs; it does not replace a test. If the agent names a layer "Frame 12" and contrast fails, the canvas got faster and the product got worse. Keep the same ready checklist as always: focus, accessible name, error state, real copy.
Figma's bet (canvas as platform, skills as executable documentation) pays back a team that already wrote the rule. For everyone else, MCP makes the absence visible. A one-week experiment is enough if the ready bar is written down before anyone opens a production file.
If your company is weighing something similar, reach me on LinkedIn or WhatsApp.
