Skip to main content
Glama
Sign In
figmcp

figmcp

by irshadio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Get Design Context

get_design_context
Read-only

Fetches design context for a Figma node, returning reference code, assets, screenshot, and variables for Flutter, HTML, or React design-to-code workflows.

Instructions

Get design context for a Figma node — the primary tool for design-to-code workflows. Returns reference code (Flutter widgets for Flutter projects, HTML + Tailwind for static sites, React + Tailwind otherwise), the assets it uses, a screenshot and the variables in the node. The code must be adapted to the target project. Use the nodeId parameter to specify a node id; from a URL like https://figma.com/design/:fileKey/:fileName?node-id=1-2 the node id is 1:2. With no nodeId the current selection in Figma is used. Large nodes return metadata instead of code unless forceCode is set.

Input Schema

NameRequiredDescriptionDefault
pageNoReact and HTML: draw the node as a web page that fills the viewport, never narrower than the design, with full-width sections stretching (default: frames 768 or more wide).
nodeIdNoThe ID of the node, eg. "123:456" or "123-456" (instance ids like "I1:2;3:4" work too). Omit it to use the current selection in Figma.
screenNoDraw the node as a phone screen that fills the screen and scrolls when tall (default: portrait frames 300-480 wide).
fileKeyNoThe key of the Figma file. Accepted for compatibility; the file open in Figma Desktop is always used.
assetsDirNoFolder of the asset files in the code. Flutter default: the svg/png/images folders of the project's pubspec.yaml, else assets/figma. React default: public/figma (static/figma for SvelteKit), loaded by URL (/figma/name.svg). HTML default: assets/figma, relative to the page.
forceCodeNoAlways return code, even for very large nodes.
frameworkNoCode to generate: react, html or flutter. Default: from clientFrameworks / clientLanguages, else FIGMA_LOCAL_MCP_FRAMEWORK, else flutter when the project has a pubspec.yaml, html for a static site (index.html without package.json), else react.
screenUtilNoFlutter: write lengths with flutter_screenutil (.w, .h, .r, .sp) so the layout scales from the design size (default: when the project's pubspec.yaml depends on flutter_screenutil).
skillNamesNoAccepted for compatibility (logging only).
clientLanguagesNoComma separated languages of the client, e.g. "dart" (picks the framework).
clientFrameworksNoComma separated frameworks of the client, e.g. "flutter" (picks the framework).
excludeScreenshotNoLeave the screenshot out of the response.
disableCodeConnectNoDraw mapped components from their layers instead of naming the code component.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / assetsDir / description
      Previous value: -"Flutter: folder of the asset paths in the code (default: the svg/png/images folders of the project's pubspec.yaml, else assets/figma)."New value: +"Folder of the asset files in the code. Flutter default: the svg/png/images folders of the project's pubspec.yaml, else assets/figma. React default: public/figma (static/figma for SvelteKit), loaded by URL (/figma/name.svg). HTML default: assets/figma, relative to the page."
    • changedInput schema / properties / framework / description
      Previous value: -"Code to generate: flutter or react. Default: from clientFrameworks / clientLanguages, else FIGMA_LOCAL_MCP_FRAMEWORK, else flutter when the project has a pubspec.yaml, else react."New value: +"Code to generate: react, html or flutter. Default: from clientFrameworks / clientLanguages, else FIGMA_LOCAL_MCP_FRAMEWORK, else flutter when the project has a pubspec.yaml, html for a static site (index.html without package.json), else react."
    • changedInput schema / properties / framework / enum
      Previous value: -[
-  "react",
-  "flutter"
-]New value: +[
+  "react",
+  "html",
+  "flutter"
+]
    • addedInput schema / properties / page
      Added value: +{
+  "description": "React and HTML: draw the node as a web page that fills the viewport, never narrower than the design, with full-width sections stretching (default: frames 768 or more wide).",
+  "type": "boolean"
+}
    • changedInput schema / properties / screen / description
      Previous value: -"Flutter: draw the node as a phone screen that fills the screen and scrolls when tall (default: portrait frames 300-480 wide)."New value: +"Draw the node as a phone screen that fills the screen and scrolls when tall (default: portrait frames 300-480 wide)."
  2. First observedv1.5.1

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only readOnlyHint/openWorldHint, yet the description discloses the substantive behaviors an agent needs: output varies by framework, the code is reference-only and 'must be adapted,' large nodes degrade to metadata unless forceCode is set, and the response bundles assets/screenshot/variables. These are non-obvious runtime traits well beyond the annotation layer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose and return contents, then moves to invocation mechanics (nodeId/selection) and the large-node caveat. Every sentence carries information – no restatement of the title and no filler – despite covering a lot of ground.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 13 parameters, zero required fields and no output schema, the description carries the burden of explaining the response and does so (code flavor by framework, assets, screenshot, variables, metadata fallback). An agent has enough to invoke it correctly without the schema filling gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the 13 parameters are already documented and a baseline of 3 applies. The description adds genuine value on top, notably the URL-to-nodeId mapping convention (node-id=1-2 → 1:2) and the selection-default and forceCode override behaviors, which go beyond the raw schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a specific verb+resource ('Get design context for a Figma node') and immediately positions it as 'the primary tool for design-to-code workflows,' which distinguishes it from get_metadata, get_screenshot and get_variable_defs. It then enumerates exactly what comes back (reference code, assets, screenshot, variables), so an agent knows its role without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operative conditions: how to derive nodeId from a Figma URL, and that omitting nodeId falls back to the current selection. The 'primary tool for design-to-code workflows' framing tells the agent when to reach for it, but it never names an alternative (e.g. get_screenshot when only an image is needed) or a when-not-to-use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools