Loading ToolBench
MCP server for mapping Figma designs to design system components
This MCP server has significant definition quality gaps across all dimensions. While tool names follow verb_noun conventions (scan_repository, analyze_figma_design, etc.), most tools lack adequate parameter descriptions, and schemas are either missing or severely incomplete. The server exposes 5 tools but provides minimal guidance for LLM selection and proper invocation. Parameter documentation is sparse, most params lack descriptions beyond a single clause. Error handling is rudimentary (generic 'Error executing tool' message). No validation of input constraints, no guidance for recovery, and no structured output schemas documented. This server would not pass code review for production use.
Analyze Figma design and match components
Generate complete implementation guide from Figma design
Generate React component from Figma design (NEW)
Get details about a specific component
Scan and load components from the design system repository
scan_repository has an empty input schema (type:object, no properties). LLMs cannot infer required context, retry logic, or parameter constraints. This violates the critical rule: 'If a tool has NO input schema at all: its schema score MUST be 0.' The tool needs explicit parameters (e.g., repo_path, scan_depth, include_variants) with descriptions.
Most parameter descriptions are minimal (under 30 chars) or missing context. E.g., 'figma_url' is described as 'Figma design URL' but does not explain the expected format (full URL vs node link), whether it requires authentication, what happens if the URL is invalid, or examples of valid formats.
No output schemas documented for any tool. LLMs do not know what fields to expect from responses, making it impossible to chain tools or extract relevant data. E.g., does analyze_figma_design return component_ids, confidence_scores, matched_patterns? Without documented output, agents resort to guessing, leading to errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 20 | - | v1 |
No error recovery guidance. The CallToolRequestSchema handler returns a generic 'Error executing tool: <message>' for all failures. There is no categorization of errors (retryable vs user-fixable vs fatal), no suggestions for next steps, and no invalid-value feedback. Per pattern:recovery-guide, error responses must tell the LLM what to do next.
Parameters 'node_id' and 'component_name' lack type constraints and format guidance. 'node_id' has no description of expected format (UUID? alphanumeric string? prefixed node ID from Figma API?). Per pattern:constrained-input, free-form strings invite hallucinated values; these should have regex patterns, enums, or explicit format descriptions.
Tool descriptions vary wildly in length and completeness. 'Analyze Figma design and match components' (51 chars) is too brief, it does not explain WHEN to use this vs generate_implementation_guide, what 'match components' means, or what the output reveals.
generate_implementation_guide and generate_react_from_figma perform write operations (per Risk:WRITE tag) but have no confirmation step or dry-run mode. Per pattern:confirmation-request, irreversible operations should support a dry-run or explicit confirmation to prevent agents from accidentally generating and committing bad code.
No validation hints in descriptions. Parameters like 'figma_url' should specify: 'Must be a valid Figma file URL (format: https://www.figma.com/file/<FILE_ID>/...)'. Current descriptions omit format constraints entirely, forcing LLMs to invent valid inputs and agents to fail on malformed URLs.