Loading ToolBench
MCP server for rapid UI iteration - create and compare multiple UI variants side-by-side
The server defines 7 tools with explicit schemas and descriptions present in src/mcp/server.ts. However, multiple critical quality gaps prevent a higher score. Tool descriptions are terse (10-50 chars), many lack actionable context about when to use them or what they return. Parameter descriptions exist but are minimal. No output schemas are documented, LLMs cannot predict return structures. Error handling is absent from tool definitions; no recovery guidance or error classification. Parameters lack validation hints (e.g., variantId format, baseRef constraints). No enum constraints for constrained inputs. The server operates over STDIO only, which caps protocol readiness at 50. Tool naming follows verb-noun convention (positive), but composition and idempotency are undocumented. This is a typical C-grade community server with functional definitions but insufficient LLM-optimization.
Check git status and working directory state
Create a new UI variation in a git worktree
List all active UI variations
Get the status of all preview servers
Remove a UI variation and its worktree
Start a development server for a UI variation
Stop the development server for a UI variation
All tools lack output schema documentation. LLMs cannot predict return structures, forcing them to guess at field names for downstream chaining. create_variation, list_variations, start_preview, preview_status must document what objects/arrays they return and which fields are guaranteed.
Tool descriptions are too terse (28-35 chars avg). They lack context on WHEN to call each tool vs. a similar one, WHAT the output contains, and any dependencies. 'Check git status and working directory state' (check_status) does not explain whether this shows variant changes, uncommitted files, or both. Expand to 50-150 chars with actionable context.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Parameter descriptions are minimal and lack validation constraints. 'variantId' (in remove_variation, start_preview, stop_preview) says 'ID of the variation to remove' but does not specify format (numeric, alphanumeric, max length). 'baseRef' in create_variation lacks detail on valid git reference formats and whether it must exist. Add constraints to every param description.
No error handling guidance. Tools provide no recovery hints or error classification. If create_variation fails due to a bad baseRef or if start_preview fails because no preview server could start, the LLM has no actionable next step. Add error-handling documentation to all tools, especially destructive (remove_variation) and state-changing (create_variation, start_preview) ones.
Destructive tool (remove_variation) lacks confirmation or dry-run support. Agents make mistakes, a confirm pattern or a 'simulate' mode would prevent accidental deletion of variant worktrees. Current design allows one-step destructive operations with no recovery path.
No tool composition guarantees. If create_variation returns a variantId, do downstream tools like start_preview accept that variantId? If list_variations returns variants with an 'id' field, does start_preview accept 'id' or 'variantId'? Undocumented field naming mismatches break agent chains.
No input validation constraints. Parameters lack enum, pattern, min/max, or format declarations. 'description' in create_variation has no length limits; LLMs could pass 10KB strings that break branch naming. 'baseRef' lacks a regex or enum of valid git references.
Idempotency not documented. Can create_variation be called twice with the same description without creating duplicate variants? Can start_preview be called twice on the same variantId safely? Agents retry on ambiguous failures, idempotency guidance prevents duplicate side effects.
No pagination or result limits documented. If list_variations returns many variants, is the response capped? Are there offset/limit parameters? Large results blow context windows; pagination is essential for list tools.