Loading ToolBench
The AI-native design engineering platform, as one MCP server: extract Figma or live-web designs into a shared semantic design graph and verify your code against it with a built-in loop (design → code), OR turn a prompt into a full, on-brand Figma design directed by an AI design director that researches references, extracts a brand, and critiques its own render (prompt → design). No REST rate limits, no metered tool-call quotas, no extra API key. Works on every Figma plan including Free. Drop-in alternative to Figma's Dev Mode MCP and Framelink for Claude Code, Cursor, Windsurf, and any MCP-compatible AI coding agent.
Plumb MCP exhibits significant definition quality gaps across the 28 tools. While tool names follow verb_noun conventions well (plumb_status, plumb_outline, plumb_node), descriptions are inconsistent in length and specificity. Critical issues: (1) Input schemas are visible for only 6 of 28 tools (plumb_node, plumb_assets, plumb_screenshot, plumb_describe, plumb_search, plumb_fit, plumb_query, plumb_fig_outline, plumb_fig_node, plumb_diff, plumb_audit, plumb_import_web, plumb_emit_react, plumb_scan_references, plumb_design, plumb_brand, plumb_source, plumb_review, plumb_studio_start, plumb_studio_kit, plumb_studio_page = ~20 tools have visible schemas). (2) Many tool descriptions are brief (status: 54 chars, outline: 80 chars) but lack actionable deployment guidance, prerequisites, or when-to-use context. (3) Output schemas are not documented for ANY tool, LLMs cannot infer what fields to expect, forcing trial-and-error exploration. (4) Error handling guidance is absent, no tool description explains what to do if a call fails, what's retryable, or what's fatal. (5) Parameter descriptions exist where schemas are visible but are sparse (many lack constraint documentation like min/max, allowed formats, or regex patterns). (6) No tool declares permissions, scope, or security implications. (7) Composition is weak, many tools are isolated (plumb_studio_start, plumb_studio_kit, plumb_studio_page form a workflow but are not explicitly linked). (8) Tools like plumb_fit reference ANTHROPIC_API_KEY but do not document secret injection or credential handling. Overall, the server is feature-rich but under-specified for reliable LLM use.
Export icons/images from the design with optional surgical mode (exact IDs) or manifest-only mode.
Run heuristic accessibility checks (contrast, touch-target size, semantic structure).
Extract or set brand guidelines (colors, typography, spacing) to drive design generation and code emission.
List every component definition and instance usage in the file.
Describe the layout and content of a single node in natural language.
Author and build a full design from the Design DSL (Plumb's domain-specific language for design generation).
Compare two PDS snapshots and narrate changes by role (nav/hero/footer/card) instead of raw JSON diff.
Deterministically generate React/JSX from either a PDS or a plumb_import_web result.
No output schemas documented for any of the 28 tools. LLMs cannot infer what fields to expect in responses, forcing trial-and-error exploration and increasing hallucination risk.
Input schemas missing or not visible for 8 tools (plumb_status, plumb_outline, plumb_tokens, plumb_selection, plumb_components, plumb_studio). Cannot validate parameter types or constraints.
Tool descriptions lack actionable deployment context. Most are 40 - 60 characters (below baseline 194 chars). Missing: when to use, prerequisites, expected side effects, what happens on failure. Example: 'plumb_status' is 54 chars but does not explain what 'paired Figma plugin' means or what 'bridge' is.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Extract a single node using the REST Figma API (without plugin).
List every screen/frame when using the REST Figma API path (without plugin).
Self-healing build loop: generate HTML from design, render, diff, and correct pass-by-pass until pixel-perfect. Requires ANTHROPIC_API_KEY.
Extract the same structure and semantic roles from a live URL (no Figma involved).
Extract a single node by ID or name and return its PDS (Plumb Design Spec) serialization.
List every screen/frame in the current Figma file with page/section path and node ID.
Pull a slice of the design tree by pattern (skeleton/buttons/text/components/role) when the full tree would be too big.
Blend structure diff (built vs authored) with design critique into one 0–100 review score and prioritised fix list.
Scan several live reference URLs and return a per-role (nav/hero/footer/card) style digest — concrete exemplars to inform a plumb_design DSL or plumb_studio brief.
Render a node as PNG/JPG using the Figma plugin's render pipeline.
Find nodes by name and/or type (e.g. find all buttons, all text with 'Login').
Extract whatever is currently selected in Figma (live PDS snapshot).
Retrieve or set the source assets (images, logos, reference designs) to seed design generation.
Report connection status to the paired Figma plugin and bridge.
Open or get status of Plumb Studio — a live local cockpit mirroring what your AI agent is doing with a Figma design.
Mid-flow step: build a component kit from the brand and references.
Final step: compose the full design pages from the kit and brief.
Begin the transparent step-by-step studio flow: research references and extract brand.
Extract design tokens (colors, typography, spacing, shadows, borders) from the current file.
Diff your rendered layout against the Figma design and return structured deltas (pixels, colors, text, hierarchy).
No error handling guidance in any tool description. LLMs have no recovery path if a call fails. Missing: categorization (retryable vs fatal), suggested next steps, actionable error messages. Per pattern 'recovery-guide', errors must tell the LLM what to do next.
plumb_fit references 'ANTHROPIC_API_KEY' but tool description does not document secret injection, credential requirements, or security implications. Per pattern 'secret-injection', credentials must never appear as tool parameters and must be documented.
No tools declare permissions, scope, or security implications. Pattern 'scope-declaration' requires each tool to state what permissions it requires (e.g., 'read:figma', 'write:figma'). This prevents least-privilege configurations and audit trails.
Workflow tools (plumb_studio_start, plumb_studio_kit, plumb_studio_page) depend on flowId and shared state but are not explicitly linked in descriptions. 'Tool composition' pattern requires clear chaining documentation and shared reference IDs in responses.
Parameter descriptions are sparse where visible. Many lack constraints: min/max ranges, regex patterns, allowed formats, or dependencies on other parameters. Example: plumb_screenshot 'scale' parameter has no documented range, LLM could pass 0, 1000, or -1.
No pagination documented for list-returning tools (plumb_outline, plumb_components, plumb_scan_references). Large result sets could exceed context windows. Per pattern 'paginated-result', tools returning lists must accept limit/offset and return total count or next_cursor.
Destructive/write tools (plumb_fit, plumb_design, plumb_brand, plumb_source, plumb_studio_start/kit/page) do not offer dry-run, confirmation, or recovery paths. Per pattern 'confirmation-request', irreversible operations should support preview or undo.