Loading ToolBench
Model Context Protocol server for Figma that provides tools for reading design information and writing/creating designs in Figma files
The Figma MCP server has 15 well-defined tools with complete JSON schemas and descriptions. All tools follow verb_noun naming convention (validate_token, get_file_info, create_frame, etc.). Most descriptions are present and reasonably detailed (100-250 chars). However, several critical gaps reduce the score: (1) Output schemas are not documented anywhere, the source shows input schemas but no return type documentation, which prevents LLMs from planning downstream operations. (2) Parameter descriptions are present but inconsistent in depth and actionability; some lack format/constraint guidance. (3) Error handling patterns are not visible in tool definitions, no recovery guidance, categorization, or actionable error messages documented. (4) No parameter-level validation constraints (min/max for numeric fields, regex patterns for strings). (5) Write-mode tools (create_frame, create_shape, create_text, create_component, create_component_instance) lack confirmation/dry-run patterns despite being irreversible. (6) Cross-tool composition is weak, no documented chaining paths or required output fields for downstream calls. These are the primary drivers pushing the score into the low 60s rather than 70+.
Create a new component in a Figma file
Create an instance of a component in a Figma file
Create a new frame/artboard in a Figma file
Create a new shape (rectangle, ellipse, polygon) in a Figma file
Create a new text element in a Figma file
Delete a node from a Figma file
Detect responsive variations of components
No output/return schemas documented for any tool. LLMs cannot infer what fields are returned, preventing intelligent chaining and response parsing. All 15 tools lack documented return types.
Write-mode tools (create_frame, create_shape, create_text, create_component, create_component_instance) lack confirmation/dry-run safety patterns. These are irreversible operations that could silently corrupt a user's design if an LLM makes a mistake. No tool description warns of side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 8 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Detect component variants and group them
Extract color, text, and effect styles from a Figma file
Get image URLs for nodes in a Figma file
Get basic metadata about a Figma file
Get detailed information about a specific node (component, frame, etc.)
Get variables and variable collections from a Figma file (new Figma Variables API)
Identify UI components in a Figma design (charts, tables, forms, etc.)
List all available components in the current Figma file
Set effects (shadows, blurs, etc.) on a node in a Figma file
Set the fill color/properties of a node in a Figma file
Set the stroke properties of a node in a Figma file
Intelligently create a design element based on type and properties
Switch to write mode to create or update designs
Update properties of a node in a Figma file
Test if the configured token has access to a Figma file
No error handling guidance visible in tool definitions. No documented recovery steps, error categorization (retryable vs user-fixable vs fatal), or actionable error messages. Agents will be unable to recover gracefully from failures.
Numeric parameters (x, y, width, height, scale, scaleX, scaleY) lack min/max constraints in descriptions. No guidance on valid ranges, allowing LLMs to pass invalid values like negative dimensions or extreme scales.
Description quality inconsistent. Some tools have vague descriptions (e.g., 'Detect responsive variations of components', does not explain WHAT is detected or HOW to use results). Others lack actionable context about when to call them.
Optional parameters lack clear defaults. For example, get_node_details has 'detailLevel' enum with no explicit default stated, and get_assets 'format' and 'scale' have defaults only mentioned in descriptions, not in schema. LLMs may not infer correct defaults.
No tool composition guidance. No documented chaining paths (e.g., 'First call identify_components, then pass nodeId to get_node_details'). No explicit output field references that downstream tools depend on, making multi-step workflows opaque.