ArchitectureTechnical Deep Dive

How Figma Skills Work

Figma opened the canvas to AI agents on March 24, 2026. Under the hood: an MCP server with 16 tools, a markdown-based skill format, and distribution across four agent platforms.

This is a complete technical breakdown of the architecture based on Figma's open-source mcp-server-guide repository. How the MCP server works, what each tool does, how skills are structured, and how they distribute across platforms.

The MCP server

Figma runs a single MCP server at mcp.figma.com/mcp using Streamable HTTP. Every Figma skill connects to this one endpoint. The server follows the MCP registry schema and exposes 16 tools organized into four groups.

Tool	What it does	Group
get_file_context	File metadata, pages, canvas structure	Read
get_design_context	Design details for a specific node	Read
get_code_context	Code-oriented view of a node	Read
get_node_image	Export a node as an image	Read
get_screenshot	Screenshot the current canvas view	Read
search_nodes	Find nodes by name or type	Read
get_page	Get a page's structure	Read
get_variables	Read variables and tokens	Read
get_styles	Read shared styles	Read
get_components	Read components from libraries	Read
create_node	Create new nodes on canvas	Write
edit_node	Modify existing nodes	Write
delete_nodes	Remove nodes from canvas	Write
set_selection	Select nodes in the canvas	Navigation
set_viewport	Control the canvas viewport	Navigation
use_figma	Execute arbitrary JavaScript in Plugin API	Execution

10 read tools, 3 write tools, 2 navigation tools, and 1 execution tool. The read-heavy distribution reflects the primary use case: agents read the canvas, reason about it, then make targeted changes.

use_figma: the power tool

Most MCP tools are structured: pass parameters, get a result. use_figma is different. It executes arbitrary JavaScript inside Figma's Plugin API runtime. You send it a string of JavaScript, Figma runs it inside the active document, and returns whatever the script explicitly returns.

Critical rules

Atomic execution: the entire script runs as one unit. No partial execution, no streaming, no progress callbacks.

Must return values explicitly. The last expression is not auto-returned. Use return statements.

No console.log. Output only comes from the return value.

No top-level await. Async operations must use Figma's Plugin API patterns.

Scripts run in the context of the current document. They can read and modify any node the plugin has access to.

Complex operations (like generate-library's 100+ calls) are fragile because each call is independent with no shared state between them.

This is what makes Figma skills powerful within the canvas. An agent can do anything the Plugin API allows: create complex component hierarchies, apply auto-layout, set constraints, read and write variables, traverse the node tree. The tradeoff is that all of this stays inside Figma. The script cannot make HTTP requests, read files, or interact with anything outside the canvas.

The SKILL.md format

Every Figma skill is a markdown file with YAML frontmatter. The format is convention-based with no formal schema or validator.

Frontmatter fields

name

RequiredIdentifier for the skill. Used by agents to reference it.

description

RequiredWhat the skill does. Agents use this to decide when to invoke it.

disable-model-invocation

OptionalBoolean. When true, the agent will not auto-invoke this skill. User must trigger it explicitly.

The body is pure markdown. Figma's built-in skills use convention-based sections, but nothing enforces them. Common sections include:

Overview

High-level summary of the skill's purpose

Pre-flight Checklist

Steps to verify before starting the workflow

Critical Rules

Hard constraints the agent must follow

Step-by-step Workflow

The main instruction sequence

Reference Documentation

Tables linking to references/ directory files

User Checkpoints

Pauses where the agent asks for human approval

Supporting directories

references/Markdown documentation files that skills reference in tables. These give agents deeper context about APIs, patterns, or constraints.

scripts/JavaScript files designed for use with use_figma. Pre-written scripts that agents pass to the execution tool. The generate-library skill uses 9 of these.

The 7 built-in skills

Figma ships 7 skills ranging from simple file creation to complex multi-phase design system generation. Complexity varies significantly.

figma-create-new-fileSimple

Creates a new Figma file. Minimal skill, mostly a wrapper around create_node.

figma-useFoundational

The base skill for Plugin API interaction. 17 critical rules for use_figma. Pre-flight checklist. 11 reference documents.

figma-implement-designModerate

Figma-to-code workflow. 7 steps: read design, extract tokens, map to components, generate code, validate output.

figma-code-connect-componentsModerate

Maps Figma components to code components using Code Connect. Bridges the design-code gap at the component level.

figma-generate-designHigh

Code-to-Figma. Builds screens on the canvas from code descriptions. Includes design system discovery and multi-step construction.

figma-generate-libraryVery High

Multi-phase design system builder. 20 to 100+ use_figma calls. 5 phases with user checkpoints. 7 reference files and 9 JavaScript scripts.

figma-create-design-system-rulesStrategic

Generates CLAUDE.md, AGENTS.md, and .cursor/rules/ from a Figma file. Encodes design constraints as persistent project rules.

Design system rules: the persistence mechanism

The create-design-system-rules skill deserves its own section because it does something the other six do not. Instead of performing a task and ending, it generates files that persist in your project and shape every future agent interaction.

What it generates

CLAUDE.md

Project-specific design rules for Claude Code. Defines component naming conventions, spacing systems, color usage patterns, and workflow constraints.

AGENTS.md

Platform-agnostic design rules. Same content adapted for any agent that reads markdown project files.

.cursor/rules/

Cursor-specific rule files. Integrates with Cursor's built-in rules system for design-aware code generation.

These generated rules encode a specific workflow: read design context from Figma first, take a screenshot for visual reference, implement the design, then validate against the Figma source. Once these files exist in a project, every agent session inherits them automatically.

Distribution: four platforms, one server

Figma distributes skills as platform-specific plugins. Each plugin manifest declares the MCP server connection and skill locations. The server is always the same. The packaging changes per platform.

Platform	Plugin location	Format
Claude Code	.claude-plugin/plugin.json	Standard plugin manifest with skills/ directory
Cursor	.cursor-plugin/plugin.json	Plugin manifest referencing skills/ and .mcp.json
GitHub Copilot	.github/plugin/plugin.json	GitHub-specific plugin directory structure
Kiro	figma-power/POWER.md	Router pattern with readPowerSteering() dispatching to steering files

The Kiro integration uses a different format entirely. POWER.md files use YAML frontmatter with a displayName, keywords, and author field. The body acts as a router, parsing user intent and dispatching to “steering” markdown files. Three steering paths are available: implement-design, code-connect-components, and create-design-system-rules.

All four platforms connect to the same MCP endpoint. The plugin version across all manifests is v2.0.2. Authentication is handled per-platform through their respective MCP connection flows.

How it all connects

Agent (Claude Code / Cursor / Copilot / Kiro)
  |
  |  reads SKILL.md for workflow instructions
  |
  v
Plugin Manifest (.claude-plugin / .cursor-plugin / .github/plugin)
  |
  |  declares MCP server connection
  |
  v
MCP Server (mcp.figma.com/mcp, Streamable HTTP)
  |
  |  exposes 16 tools
  |
  +---> Read tools (10)    get_design_context, get_variables, etc.
  +---> Write tools (3)    create_node, edit_node, delete_nodes
  +---> Nav tools (2)      set_selection, set_viewport
  +---> use_figma (1)      arbitrary Plugin API JavaScript
          |
          |  executes inside Figma runtime
          |
          v
      Figma Canvas (Plugin API context)
          |
          |  reads/writes nodes, variables, styles, components
          |
          v
      Result returned to agent

Limitations of this architecture

Figma Skills are a strong first step toward agent-native design tooling. But the architecture has structural boundaries worth understanding before you build on it.

Canvas-locked execution

Every skill operates within Figma's runtime. use_figma scripts cannot make HTTP requests, read local files, or interact with anything outside the canvas. An agent can read your design system in Figma but cannot validate it against your production codebase in the same workflow.

Single MCP dependency

All 7 skills depend on one endpoint: mcp.figma.com/mcp. If the server is rate-limited, slow, or down, every skill stops. There is no offline mode, no local fallback, no caching layer.

No runtime design judgment

Skills are static instructions. They tell agents HOW to interact with Figma but provide no judgment about whether the output is good. A skill can say "apply 8px grid spacing" but cannot evaluate whether that spacing works for the specific component, context, or brand.

No cross-tool composition

Skills cannot chain with other MCP servers natively. There is no mechanism for a Figma skill to say "now validate this through a different service" or "now check this against the production API." Each skill is an island.

Convention over schema

The SKILL.md format has no formal schema, no validator, no type system. The YAML frontmatter requires only name and description. Quality depends entirely on the markdown content. This makes third-party skill authoring unpredictable.

Monolithic execution model

use_figma runs entire scripts atomically. No streaming, no partial results, no progress callbacks. Complex operations like generate-library (which requires 100+ sequential calls) become fragile. A failure at call 80 means starting over.

No portability

Skills reference Figma-specific tool names throughout (get_design_context, use_figma, get_variables). A Figma skill cannot run against Penpot, Framer, or any other design tool without a complete rewrite.

Figma Skills vs skill.design: Side-by-Side Comparison

How Figma's built-in skills compare to open, vendor-agnostic alternatives. Comparison table, feature breakdown, and open Figma skills you can install now.

Also: skill.design vs Google Stitch Skills

Same pattern, different vendor. How Stitch skills compare.

Browse all skills in the registry

Engineering, Security, Data, Marketing, Design, and more

Frequently asked questions

What is a Figma skill?+

A Figma skill is a markdown file (SKILL.md) that teaches an AI coding agent how to perform a specific task using Figma's MCP server. Skills contain step-by-step instructions, critical rules, and references that guide the agent through workflows like building a design system, implementing a design in code, or auditing components.

How does use_figma work?+

use_figma is an MCP tool that executes arbitrary JavaScript inside Figma's Plugin API runtime. You pass it a JavaScript string, Figma runs it atomically inside the active document, and returns the result. The script must explicitly return values. No console.log, no top-level await. It is the most powerful tool in Figma's MCP server because it gives agents direct programmatic access to the canvas.

What is the SKILL.md format?+

SKILL.md is a markdown file with YAML frontmatter containing a name and description. The body uses convention-based sections like Overview, Pre-flight Checklist, Critical Rules, and Step-by-step Workflow. There is no formal schema or validator. Skills can include optional references/ and scripts/ directories for supporting documentation and JavaScript files.

Which platforms support Figma skills?+

Figma distributes skills as plugins for four platforms: Claude Code (.claude-plugin/plugin.json), Cursor (.cursor-plugin/plugin.json), GitHub Copilot (.github/plugin/plugin.json), and Kiro via a separate POWER.md format. All platforms connect to the same MCP server at mcp.figma.com/mcp using Streamable HTTP.

How many MCP tools does Figma expose?+

Figma's MCP server exposes 16 tools: get_file_context, get_design_context, get_code_context, get_node_image, get_screenshot, search_nodes, get_page, create_node, edit_node, delete_nodes, set_selection, set_viewport, use_figma, get_variables, get_styles, and get_components.

Can I create my own Figma skill?+

Yes. A Figma skill is a markdown file with YAML frontmatter. Write a SKILL.md with name and description in the frontmatter, add your workflow instructions in the body, and optionally include references/ for documentation and scripts/ for JavaScript files. There is no build step, no compilation, no registration required. You can also design skills visually at skill.design/designer.

What is the difference between Figma skills and skill.design skills?+

Figma skills are agent prompts coupled to Figma's MCP server and Plugin API. They operate within the Figma canvas. skill.design skills are vendor-agnostic markdown files that work across any agent platform and can orchestrate multiple tools and services, not just Figma.

What does create-design-system-rules do?+

It is the most strategically significant Figma skill. It analyzes a Figma file's design system and generates persistent rule files: CLAUDE.md for Claude Code, AGENTS.md for other agents, and .cursor/rules/ for Cursor. These files encode design constraints and workflow assumptions that shape every future agent interaction in the project.

Build your own skills

Figma skills are one flavor. The skill format is open. Design skills for any tool, any agent, any workflow.

Open Designer See Figma Skills