Skip to main content
Glama
southleft

figma-console-mcp

by southleft

figma_instantiate_component

Creates a Figma component instance from design system identifiers, using both componentKey and nodeId to support published and local components.

Instructions

Create an instance of a component from the design system.

CRITICAL: Always pass BOTH componentKey AND nodeId together! Search results return both identifiers. Pass both so the tool can automatically fall back to nodeId if the component isn't published to a library. Most local/unpublished components require nodeId.

IMPORTANT: Always re-search before instantiating! NodeIds are session-specific and may be stale from previous conversations. ALWAYS search for components at the start of each design session to get current, valid identifiers.

VISUAL VALIDATION WORKFLOW: After instantiating components, use figma_take_screenshot to verify the result looks correct. Check placement, sizing, and visual balance.

Input Schema

NameRequiredDescriptionDefault
nodeIdNoThe node ID from search results. ALWAYS pass this alongside componentKey - most local components need it.
variantNoVariant properties to set (e.g., { Type: 'Simple', State: 'Active' })
parentIdNoParent node ID to append the instance to
positionNoPosition on canvas (default: 0, 0)
overridesNoProperty overrides (e.g., { 'Button Label': 'Click Me' })
componentKeyNoThe component key from search results. Pass this WITH nodeId for automatic fallback.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4.5/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 behavioral burden and does so well: it discloses identifier fallback behavior, session-specific nodeId staleness, the need to re-search, and a post-instantiation validation workflow. These are important operational traits beyond 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.

Conciseness4/5

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

The purpose is front-loaded, followed by clearly labeled critical guidance and validation workflow. It is slightly repetitive and heavily emphasized, but every section provides actionable information.

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 six-parameter creation tool with no annotations or output schema, the description covers the essential operational context: valid identifiers, staleness risks, fallback behavior, and verification. It does not describe permissions or return values, but the core invocation guidance is complete.

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 description coverage is 100%, so the baseline is 3, but the description adds meaningful semantics about the componentKey/nodeId relationship and fallback behavior. It does not add much for variant, overrides, parentId, or position beyond what the schema already documents.

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?

The description states a specific verb and resource: "Create an instance of a component from the design system." This clearly distinguishes it from sibling tools like figma_search_components and figma_get_component_details, which retrieve rather than instantiate components.

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?

It gives clear workflow context: search first, pass both identifiers, then use figma_take_screenshot for visual validation. It does not explicitly compare against alternatives such as cloning a node, but the intended usage is clear.

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