Skip to main content
Glama
irshadio

figmcp

by irshadio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_design_context

Fetch Figma node design context and return reference Flutter or React + Tailwind code, assets, screenshot, and variables for 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, 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

TableJSON Schema
NameRequiredDescriptionDefault
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.
screenNoFlutter: draw 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.
assetsDirNoFlutter: folder of the asset paths in the code (default: the svg/png/images folders of the project's pubspec.yaml, else assets/figma).
forceCodeNoAlways return code, even for very large nodes.
frameworkNoCode 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.
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. First observedv1.5.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the return payload (reference code, assets, screenshot, variables), that the code must be adapted to the target project, framework-dependent output, and the large-node fallback governed by forceCode. This is material behavioral context an agent cannot infer from the schema.

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?

Dense but front-loaded: purpose first, then return contents, then nodeId usage, then the large-node caveat. Every sentence contributes actionable information with no filler.

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

Completeness4/5

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

For a 12-parameter tool with no annotations and no output schema, the description covers the critical behaviors (output shape, framework selection, node targeting, size fallback). Remaining per-parameter Flutter nuances (screen, assetsDir, screenUtil) are left to the schema, which documents them at 100% coverage.

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 baseline is 3, but the description adds real value beyond the schema by explaining the Figma URL → node id translation ('node-id=1-2' becomes '1:2') and the selection default, which the schema only partly states.

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?

States a specific verb+resource ('Get design context for a Figma node') and explicitly positions itself as 'the primary tool for design-to-code workflows', distinguishing it from siblings like get_screenshot and get_metadata. It also enumerates the concrete artifacts returned (code, assets, screenshot, variables).

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?

Give clear operational context: nodeId specifies the node, the URL-to-node-id mapping is spelled out, and omission falls back to the current Figma selection. It also warns when large nodes yield metadata rather than code. It stops short of naming alternative siblings or when NOT to use this tool.

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