Loading ToolBench
Extract the complete design language from any website and ship it — clone to a working Next.js starter, guard tokens with a CI drift bot, or browse everything in a local studio. Outputs W3C DTCG tokens, motion tokens, typed anatomy stubs, Tailwind config, and ready-to-paste v0 / Lovable / Cursor / Claude-Artifacts prompts.
designlang offers a well-structured set of design-extraction tools with generally clear naming and reasonable descriptions. However, the server has several gaps: (1) many parameter descriptions lack detail about constraints, ranges, or formats; (2) output schemas are not documented in the tool definitions themselves (LLMs cannot see what get_colors or get_tokens return); (3) error handling guidance is minimal, tools do not explain what to do if a job fails or a job_id is invalid; (4) parameter relationships (e.g., 'job_id must refer to a completed job before calling get_tokens') are underdocumented. The tool set is cohesive and follows a clear job-based async pattern, which is good for composition. Naming is mostly strong (verb_noun convention observed). However, the lack of returned output schema documentation means LLMs must infer downstream behavior, reducing confidence in tool chaining.
Cancel a running extraction job; its result is discarded.
Compare two finished jobs (e.g. production vs a preview deploy): colours, typography, spacing, accessibility and components that changed.
Render a finished job in a target format.
Extract the design system of a live URL in a real browser. Returns a job_id immediately; poll get_job_status, then pass the job_id to get_tokens, get_colors, get_typography, get_components, get_findings, compute_drift or export.
Find the nearest palette color that passes the requested WCAG contrast rule against the given hex.
Colour system for a finished job: primary/secondary/accent, backgrounds, text, full palette with usage.
Output schemas not documented. Tools like get_tokens, get_colors, get_typography, get_components, get_findings return complex structured data, but tool definitions do not document what fields are in those responses. LLMs cannot plan downstream tool calls without knowing return structure.
Parameter descriptions lack constraint details. 'url' parameter in extract_design says 'page to extract, e.g. stripe.com' but does not specify whether to include https://, what happens with invalid URLs, or timeout behavior. 'width' and 'height' lack ranges (min/max pixels). 'wait' does not specify millisecond range or upper bound.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Return the component cluster with matching kind, optionally narrowed to a variant index.
Component styles for a finished job: buttons, inputs, cards, links and their variants.
Design-system quality findings for a finished job: token lint (colour sprawl, scale consistency) and WCAG contrast summary.
Status of an extraction job (running, done, failed, cancelled). A done job includes a short summary: primary colour, font families, counts.
Return the region with the given role (e.g. hero, nav, footer).
W3C DTCG design tokens (primitive + semantic tiers) for a finished job.
Typography for a finished job: families, type scale, weights, line heights.
Return the accessibility remediation array (failing fg/bg pairs with suggestions).
All extraction jobs in this session.
Case-insensitive substring match over all token dot-paths.
Error handling guidance missing. No tool description explains what the LLM should do if a job fails, if a job_id is invalid/expired, or if a requested export format is unavailable. Error responses likely return error codes but not recovery instructions.
Parameter relationships underdocumented. get_tokens, get_colors, etc. all require job_id to refer to a *completed* job (status='done'). This prerequisite is not stated in tool descriptions, forcing the LLM to discover it by trial-and-error or reason about job lifecycle.
list_jobs has no meaningful description beyond 'All extraction jobs in this session.' Does not clarify pagination, filtering, or what fields are returned. Response structure is opaque to the LLM.
get_region and get_component parameter descriptions are sparse. 'name' parameter in both tools lacks examples of valid region/component names and does not clarify case sensitivity or available options.
list_failing_contrast_pairs has minimal description ('Return the accessibility remediation array') and no parameter details about what the returned array contains or how to interpret failure suggestions.