Loading ToolBench
MCP server that exports design files (PSD, Figma) to GUI framework code (QML, Slint, Flutter, etc.) with font mapping, layer tree inspection, and export hints
mcp-design2gui has 12 tools with descriptions and basic schemas, but the quality is significantly below production standards. Most descriptions lack actionable context for LLM tool selection, parameters are minimally documented, output schemas are not visible in the provided source, and error handling guidance is absent. Tool naming follows verb_noun convention (load_psd, import_figma, etc.), which is positive, but descriptions are generic and fail to explain WHEN to use each tool, dependencies between tools, or what to expect in responses. The server attempts to provide rich domain functionality (design-to-code export) but the tool interface does not match LLM requirements for reasoning and composition.
Generate code in the target framework (QML, Slint, Flutter, SwiftUI, React Native, LVGL) to a specified output directory
Get every font family the design references and how it currently resolves on this machine
Get detailed information for one layer including text runs, font info, shape geometry, and linked-file references
Render a layer to a bitmap for visual recognition
Get the layer hierarchy as a JSON tree with layerId and name for each node
Import a Figma file from a URL or file key. Requires FIGMA_API_KEY or FIGMA_ACCESS_TOKEN environment variable, or pass apiKey explicitly via options
List available export formats with their configuration options and output structure
Output schemas are not documented. The rubric requires 'LLMs need to know what fields to expect so they can plan downstream tool calls.' None of the 12 tools in the source code show return type definitions, JSON Schema output specifications, or field descriptions. This forces LLMs to guess what get_layer_tree(), import_figma(), or export() actually return, breaking tool composition and chaining.
Descriptions lack WHEN-to-use context and dependencies. 'Get the layer hierarchy as a JSON tree with layerId and name for each node' (get_layer_tree) tells the LLM WHAT but not WHEN. Rubric baseline: 'Write descriptions as if prompt-engineering. State WHAT the tool does, WHEN to use it, and any prerequisites.' The prompt in main.cpp hints at a three-step workflow (load → inspect → set hints → export), but individual tool descriptions do not reference this flow. An LLM cannot understand when to call get_layer_tree vs get_layer_details without reading the 200+ line prompt text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 39 | 2026-07-28+ | v2 |
List all pages in a loaded Figma file
Load a PSD file from an absolute path
Persist in-memory export hints and font mappings to a sidecar JSON file for the current design
Set export hints on a layer to control its code generation (type, componentName, baseElement, etc.)
Set a font mapping to substitute one font family for another. global=true persists to system-wide mapping store; global=false is in-memory until save_hints is called
Parameters lack descriptions or constraints. 'options' parameter in import_figma is documented as 'JSON string with optional apiKey and hintFile properties' but does NOT enumerate valid keys, required vs optional, or the JSON structure. An LLM cannot construct a valid options JSON without trial-and-error.
No error handling guidance or recovery paths. None of the tool descriptions state what errors are possible or what the LLM should do if a call fails. For example, import_figma states 'Requires FIGMA_API_KEY or FIGMA_ACCESS_TOKEN environment variable' but does not say what error message is returned if the token is missing, whether the error is retryable, or what the LLM should tell the user.
No pagination or result limits documented. get_layer_tree() and list_exporters() offer no indication of whether they paginate, cap results, or return everything. If a design has thousands of layers, get_layer_tree() could return unbounded JSON, exhausting the context window. State the limit in the tool description.'
Tool composition is unclear. The prompt hints at a workflow (load → inspect → set hints → export) but tool descriptions do not state dependencies or required ordering. An LLM cannot infer that set_export_hint requires a prior get_layer_tree call to obtain valid layerIds, or that save_hints must be called to persist changes. Ensure tool A's output contains the IDs and references tool B needs.' Without explicit chaining guidance, agents waste tokens discovering the workflow.
Ambiguous parameter types and missing constraints. set_export_hint has a 'baseElement' parameter with enum-like values (Switch, ComboBox, TabBar, etc.) but the input schema shows type 'string' with no enum constraint. An LLM could pass invalid values like 'TextInput' or 'button', causing silent failure or error.
Descriptions under-document prerequisites and side effects. set_font_mapping has a 'global' parameter but the description does NOT make clear that global=true has IMMEDIATE, system-wide persistence, while global=false is in-memory and lost unless save_hints is called. An LLM could set a local mapping, forget to call save_hints, and experience data loss. State WHAT the tool does, WHEN to use it, and any prerequisites.'
No per-tool risk or idempotence documentation. Destructive tools (set_export_hint, set_font_mapping, save_hints, export) are marked with Risk: WRITE but descriptions do NOT state whether they are idempotent (safe to retry) or have side effects (e.g., export overwrites files). Agents need to know which calls are safe to retry and which have irreversible consequences.' Per current spec (2026-07-28), tools should declare idempotentHint, destructiveHint via annotations, none are present.