Loading ToolBench
A Node.js/TypeScript microservice that extracts design systems from websites using Playwright automation and provides an MCP interface for Cursor IDE integration
The server defines 5 tools with explicit schemas and descriptions visible in src/mcp/handlers/tools.handler.ts. All tools follow verb_noun naming (get_*, list_*) and include basic parameter documentation. However, there are significant gaps: output schemas are completely undocumented (no structured return type specs visible), parameter descriptions are minimal (1-5 words), and error handling is basic with no recovery guidance. The tools are read-only, which is good from a safety perspective, but the definitions lack the depth expected for production use. Parameter descriptions like 'The site name of the design system to retrieve' are borderline acceptable but do not state format constraints, valid values, or dependencies. No tool includes examples of return structures, making it unclear what an LLM should expect after invocation.
Get a specific component definition from a design system by component name.
Get a design system by site name. Returns the complete design system including metadata, tokens, and components.
Get component patterns from a design system.
Get design tokens (colors, fonts, spacing, etc.) from a design system.
List all available design systems by site name.
Output schemas are completely undocumented. No return type specifications visible anywhere in code. LLMs have no way to know what fields to expect from tool responses, making downstream chaining difficult and forcing blind extraction attempts.
Parameter descriptions are minimal and lack format/constraint information. 'The site name of the design system to retrieve' does not specify: is it case-sensitive? What are valid site names? Must it be pre-registered? Are there example values? This forces LLMs to guess.
Tool descriptions lack actionable context. 'Get a design system by site name' does not explain: When should an LLM call this vs get_component? What's the difference between this and get_tokens? What does 'complete design system' include? Descriptions should answer disambiguation questions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | 2024-11-05+ | v1 |
No enumeration constraints on site_name or component_name parameters. These appear to be string lookups into an internal registry. LLMs have no way to discover valid values without calling list_design_systems first, creating unnecessary round-trips.
Error handling in callTool() is basic and provides no recovery guidance. Errors like 'site_name parameter is required' are thrown but not rich enough to guide LLM recovery. No distinction between retryable vs fatal errors.
No pagination support visible. If design systems, components, or tokens can be large (> 100KB), LLMs will receive bloated responses that exhaust context windows. No limit, offset, or cursor parameters present.