Loading ToolBench
UI/UX design audit tool for Claude Code. Scores projects across 12 dimensions: color contrast, typography, accessibility, layout, and more. WCAG 2.2, APCA, and OKLCH color science. Zero dependencies.
The ui-ux-suite server provides 14 well-named, domain-specific tools with comprehensive input schemas and clear descriptions. Naming follows verb_noun conventions consistently (scan_project, extract_colors, check_contrast, generate_palette, etc.). All tools have descriptions between 54-200 characters, well within the 10-1024 character baseline. Input schemas are present and properly typed for all tools. However, there are meaningful gaps: (1) NO output schemas are documented in the code, the rubric requires 'Document the output schema' as critical, and this is entirely absent; (2) error handling descriptions are missing, tools do not explain what errors they return or recovery paths; (3) parameter descriptions are present but minimal, most lack range constraints, format specifications, or dependency documentation; (4) no tool declares what it returns or how results chain to downstream tools. The tools are well-structured for a specialized domain (design auditing) and would be usable, but fall short of production-grade A/B standards due to missing output documentation and incomplete error guidance.
Run a full 12-dimension design audit on a project. Single entry point: chains scan -> extract -> score -> report. Returns structured JSON with per-dimension scores, top findings, and a formatted markdown report. This is the canonical way to audit a project in one call.
Check contrast ratios for foreground/background color pairs. Returns WCAG and APCA scores.
Extract all color values from project CSS, Tailwind config, token files, and component styles.
Extract all spacing values: padding, margin, gap from project styles.
Extract all typography values: fonts, sizes, weights, line heights, letter spacing.
Generate a color palette from a base/brand color with semantic roles, surfaces, and dark mode.
No output schemas documented. Tools define input schemas but the code shows no return type specifications, field definitions, or response structure documentation. The rubric's critical check states 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls and extract the right data.' This is entirely absent across all 14 tools.
Error handling absent. Tool descriptions do not explain what errors can occur, which are retryable, or what guidance to give LLMs on recovery. E.g., extract_colors could fail if CSS is malformed or paths are invalid, but the description provides no guidance. The rubric requires 'Error responses must tell the LLM what to do next' and 'Categorize errors as retryable, user-fixable, or fatal.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Generate a spacing scale from a base unit.
Generate a complete design token set: color, typography, spacing, border-radius, shadows, motion.
Generate a type scale from base size and ratio.
Query the design knowledge base. Searches both the structured knowledge object and 21 markdown knowledge documents.
Query the Laws of UX knowledge base. Returns entries for Hicks Law, Fittss Law, Millers Law, Jakobs Law, Doherty Threshold, Peak-End Rule, Gestalt laws, and 18 others. Filters (all optional) compose with AND semantics.
Scan project files and build a design profile: framework, styling approach, component library, theme system, design maturity.
Score a specific design dimension (1-10) with findings.
Calculate overall weighted design score from dimension scores.
Parameter descriptions lack actionable constraints. E.g., 'projectPath' is described only as 'Root path of the project', no guidance on format, whether absolute vs relative paths are acceptable, what happens if path doesn't exist, or whether symlinks are resolved. The rubric requires 'Describe the expected format, range, and allowed values directly in the parameter description.'
No tool chaining documentation. Functions like uiux_generate_tokens and uiux_audit_run don't document what subsequent tools to call or what their outputs enable. The rubric states 'If the next likely action requires a team_id, channel_id, and message_id, the current response must return all three.' Here, after generating tokens, what tool should the LLM call next? This is undocumented.
knowledge_query and laws_query have complex, optional parameter relationships. E.g., category, key, search, and file are mutually exclusive or semi-optional, but the descriptions do not explain which combinations are valid or what happens if multiple are provided. The rubric requires 'When one parameter's valid values depend on another, document this in both parameter descriptions.'