Loading ToolBench
Content-Derived Design CLI and MCP server. Reads HTML and redesigns it from its own content (nouns, dates, numbers, colors). Generates standalone HTML output with token-specific design directions.
Strong tool definitions with complete schemas and clear descriptions. All 8 tools have explicit input schemas with typed properties and descriptions. Tool names follow verb_noun patterns (reimagine, design_auto, design_variations, design_lock, extract_content, list_tokens, audit_html, list_rules). Descriptions are substantive (100-250 chars), explaining what each tool does and when to use it. Parameters are well-typed with enums where appropriate (token enum with 11 values). However, output schemas are not documented, LLMs cannot see what fields to expect from responses. Error handling guidance is absent. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite all tools being read-only operations.
Run Design Health (deterministic rules) on HTML. Checks typography, palette, motion, content, structure and performance. Returns the verdict (CLEAN/WARNINGS/FAIL) with every finding, its severity and the offending evidence.
Inspect HTML, choose the strongest design direction, generate and score candidates, and return the winning standalone artifact with the reasoning. The source is never modified.
Capture a shipped page's design surface as reusable machine-readable data: palette by role, type stack, typographic voice, motifs, motion and structure. Feed the result back as `ref` to put new content on that brand.
Generate several content-derived directions from one source and a contrast sheet that puts them side by side. Returns ranked directions with quality, fidelity and voice, plus the HTML for every direction and the sheet itself.
Extract content from HTML: title, palette, nouns, proper nouns, dates, numbers, emails, paragraphs and anchors. Does not generate output — shows exactly what the engine finds.
Output schemas not documented. LLMs cannot see what fields to expect from tool responses (e.g., what does reimagine() return? Is it {html, audit_report}? {html, score, metadata}?). This forces LLMs to guess and wastes tokens on discovery.
No tool annotations despite all tools being read-only. Adding readOnlyHint=true to all 8 tools would signal to agents that these are safe to call without side effects and can be retried freely.
No error handling guidance. Tools lack descriptions of failure modes and recovery steps. E.g., what happens if HTML is malformed? If design generation times out? If audit rules fail to load?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
List the Design Health rule registry: code, area, severity and what each rule checks.
List all available design tokens with descriptions.
Read HTML and redesign it from its own content. Extracts nouns, colors, dates and numbers from the source, then generates a token-specific standalone page. Source facts stay source facts; only the composition changes.
list_tokens and list_rules have minimal descriptions (70 chars). Expand to explain what tokens/rules are available and when to call these discovery tools before using design tools.
design_variations 'count' parameter lacks min/max constraints in description. Should state '2-10' explicitly in the description text, not just in the schema, so LLMs understand the valid range.