MCP server for Figma design integration with AI coding tools
The server defines 2 tools with reasonable structure and Zod-based schema validation. Both tools have clear verb-noun naming (get_, download_) and substantive descriptions (150+ chars each). However, the definitions have notable gaps: output schemas are not explicitly documented in code, parameter descriptions lack format constraints and validation guidance, and error handling is generic. The tools follow single-responsibility principles but lack idempotency hints and composition details. Per-tool analysis: get_figma_data (65/100) has solid naming and description but schema lacks explicit output type documentation; download_figma_images (59/100) similarly structured but the nested 'nodes' array schema lacks detailed validation constraints. Token efficiency is reasonable (descriptions avoid examples), but actionable error recovery is absent.
Download SVG and PNG images from a Figma file. Supports both rendered node images and image fills. Images are cached locally to avoid repeated downloads.
Get layout and style information from a Figma file or specific node. Returns simplified design data including CSS styles, text content, and export info. Results are cached for 24 hours to reduce API calls.
Output schemas not explicitly documented. Neither tool describes its return type, fields, or structure. LLMs cannot plan downstream calls or extract data without knowing what fields to expect.
Parameter descriptions lack format constraints and validation rules. 'depth' accepts 1-100 but no constraint is enforced in description (just 'optional'). 'localPath' accepts 'absolute path' but no guidance on Windows vs Unix, symlink handling, or permission requirements.
Error handling is generic and provides no recovery guidance. Errors are caught but 'formatErrorForAI()' returns structured text without actionable next steps (e.g., 'Rate limit hit, retry after X seconds' or 'Invalid fileKey, call list_files() to discover valid keys').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
No idempotency or confirmation patterns for destructive operations. download_figma_images performs WRITE operations (file creation) without dry-run, confirmation, or explicit idempotency guarantees. If called twice with same params, behavior is undefined.
Pagination and result limits not documented. get_figma_data may return large design trees; no mention of max depth enforcement, caching strategy, or token optimization. Large Figma files could blow context windows.
API credentials (Figma API key) injected server-side in constructor, which is correct. However, no scope declaration or permission gating visible, tools do not advertise what permissions they require (e.g., 'read:files', 'read:images') or restrict agent capabilities.