Loading ToolBench
Figma MCP Server using FastMCP for interacting with Figma documents and design files
TalkToFigmaMCP has significant definition quality gaps. While most tools have descriptions and basic parameter information, the implementation has weak schema enforcement, generic parameter descriptions, and missing structured output documentation. Only 2 tools have fully typed parameters with descriptions. Many parameters lack type information in visible schemas. Error handling is minimal, most tools return generic error strings without recovery guidance. The server conflates read-only and write operations without distinguishing them in tool metadata. Only 1 tool (export_node_as_image) has explicit parameter constraints; others accept free-form strings. The tool descriptions are adequate (60-150 chars average) but lack WHEN to use and dependency hints. Output schemas are not documented, agents cannot plan downstream calls reliably. These gaps force LLMs to reason about ambiguous inputs and parse unstructured responses.
Export a node as an image and save to file system. IMPORTANT: Always specify a full absolute path for output_path parameter. This ensures images are saved exactly where you intend them to be. Example: output_path='/Users/username/Documents/my_project/assets/images'
Get annotations from a node or set of nodes.
Get detailed information about the current Figma document.
Get instance overrides for a component instance.
Get all local components from the current Figma document.
Get all children node IDs from a specified node, including all nested levels.
Output schemas not documented. Tools return JSON strings via json.dumps() but agents cannot infer field structure, types, or pagination. Forces LLMs to parse unstructured text and guess at fields needed for chaining.
Minimal error handling. All tools catch exceptions and return plain error strings like 'Error getting document info: <str(e)>'. No guidance for recovery, retry logic, or next steps. LLMs receive stack trace text rather than actionable error classification.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Get detailed information about a specific node in Figma.
Get detailed information about multiple nodes in Figma.
Get reactions from a node.
Get information about the current selection in Figma.
Get all styles from the current Figma document.
Join a specific channel to communicate with Figma.
Get detailed information about the current selection in Figma, including all node details.
Scan for nodes of specific types within a given node.
Scan for text nodes within a given node.
join_channel tool lacks clear purpose. Description is vague ('Join a specific channel to communicate with Figma'). No documentation of what 'channel' means in the Figma context, what happens when you join, or how this enables subsequent operations. Parameter 'channel' is a string with no enum or format constraint.
No parameter validation or constraints. Tools accept user-provided strings (node_id, channel, format) without enums, regex patterns, or type guards. Agents can pass invalid values that fail silently or produce cryptic server errors.
read_my_design is ambiguous. Name does not clearly indicate it mirrors get_selection with added details. LLMs may conflate it with read_design_file or similar. Description does not distinguish it from get_selection.
No dependency hints or multi-step guidance. Tools like get_node_info(node_id) do not explain how to discover valid node_ids (call get_document_info first, then parse). Forces agents to trial-and-error.
export_node_as_image parameter descriptions reference example paths but do not formalize path validation (absolute vs relative, directory existence checks). Description warns 'ALWAYS specify absolute path' but code may not validate this, LLM still responsible for getting it right.
No tool annotations (readOnlyHint/destructiveHint/idempotentHint). The protocol supports declaring read-only vs write semantics, but tools do not use them. LLMs cannot distinguish safe reads from state-changing operations without reading descriptions carefully.
Result limits not enforced. get_document_info, get_styles, get_local_components, and list-like tools do not document or enforce max result counts. Returning thousands of items could exhaust context window and degrade LLM reasoning.