Loading ToolBench
Figma REST API integration for design-to-code workflows
Server has 6 tools with complete input schemas and descriptions. All tool names follow verb_noun pattern (figma_get_*, figma_sync_*), which is good. However, descriptions are terse (10-75 chars), providing minimal context for LLM decision-making. No output schemas are documented, critical for agents planning downstream calls. Parameter descriptions exist but lack constraint details (ranges, formats, valid values beyond enums). The figma_export_node tool has an enum for format, which is good practice. figma_sync_tokens accepts an optional output_path but lacks explanation of where/how the file is written or what format the JSON takes. No mention of authentication handling, rate limits, or error recovery guidance. Tool composition is reasonable, each does one thing, but no tool returns the IDs needed for subsequent calls (e.g., figma_get_file should return node IDs for use in figma_get_node). Error handling code exists (validation_error, figma_error codes visible in tests) but descriptions don't explain what LLM should do next on failure.
Export a Figma node as an image (png, jpg, svg, or pdf)
Get all components in a Figma file
Get a Figma file by key
Get a specific node from a Figma file
Get all styles in a Figma file
Extract design tokens (colors, typography, spacing) from a Figma file
Output schemas are not documented. No tool describes what fields or structure it returns. LLMs cannot plan downstream calls or extract required IDs without knowing response shape.
Descriptions are uniformly terse (10 - 75 chars), below the 50 - 200 char baseline for LLM-optimized descriptions. 'Get a Figma file by key' and 'Get all components in a Figma file' lack context on WHEN to use these tools, what they return, or any prerequisites (e.g., 'Requires FIGMA_ACCESS_TOKEN environment variable').
Parameter descriptions lack constraint details. 'file_key' and 'node_id' have minimal descriptions, no guidance on format (e.g., 'file key is a 22-character alphanumeric string from the Figma URL'), expected length, or valid patterns. figma_sync_tokens output_path parameter lacks explanation of JSON structure or output location.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
No error recovery guidance in tool descriptions. Tests show validation_error and figma_error codes, but descriptions don't tell LLMs what to do on failure, e.g., 'If FIGMA_ACCESS_TOKEN is missing, ensure it is set in environment variables.' Error messages should guide next steps per pattern:recovery-guide.
Tool composition breaks chaining. figma_get_file returns file metadata, but no indication of what fields are in the response or whether it includes a list of node IDs needed for figma_get_node. A tool should return all IDs and references downstream tools need (mxe:include-chaining-ids).
figma_export_node scale parameter is numeric with no bounds (min/max). Unbounded numbers allow LLMs to pass absurd values like 1000x, which could cause timeouts or excessive API usage. Specify min and max (e.g., 0.1 - 4).
No documentation of rate limits, pagination, or result size caps. If figma_get_file or figma_get_components returns large responses (e.g., 1000s of components), no mention of pagination limits. Tool descriptions should state if results are capped and how to page through them.