Loading ToolBench
Read-only stdio MCP server exposing designesy.org's design-intelligence infrastructure — 17 tools for design-system contracts, verification scoring, drift detection, AI readiness, token validation, accessibility, motion, and composite reports.
This server exposes 15 read-only tools for design-system verification and contract analysis. All tools have names following verb_noun patterns (get_*, fetch_*, extract_*, score_*, detect_*, validate_*, assess_*, generate_*) which is positive. However, critical gaps emerge: (1) Parameter descriptions are largely absent or minimal, most tools show only type and basic field name without explaining what value to pass or what format is expected. (2) Output schemas are NOT documented anywhere in the provided source, we cannot verify what fields each tool returns, making it impossible for an LLM to plan downstream calls or extract specific data. (3) Error handling is not evident, no recovery guidance, no categorization of retryable vs fatal errors, no invalid-input examples. (4) Several tool descriptions are vague or incomplete (e.g., 'Get the agent discovery document' does not explain when to call it vs other metadata tools, or what structure it contains). The server appears well-intentioned for a specialized domain (design systems), but lacks the rigor expected of production MCP tools.
Assess design system's AI/agent readiness (presence of structured exports, machine-readable contracts)
Detect design-contract drift between a URL and the canonical contract
Extract :root { --token: value } custom properties from CSS text
Fetch a page and all its CSS (inline + linked), return concatenated text
Generate a composite design verification report (contract score + drift + accessibility + motion checks)
Get the agent discovery document (agent.json)
Get a filtered contract section (colors, motion, acoustic, etc.)
Get the Design Review kit (8 dimensions, agent prompt, output format)
No output schemas documented. The provided schema information only shows input parameters. Return types, field names, and structures for each tool are completely undocumented. This prevents LLMs from understanding what data they receive and planning downstream tool calls.
Parameter descriptions are minimal or absent. Most parameters show only a type and basic name without explaining what values are valid, what format is expected, or when the parameter is required vs optional. Example: 'url' parameter in fetch_page_css says 'URL to fetch CSS from' but does not specify format (http/https only?), length limits, or what happens if the URL is invalid or unreachable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 43 | 2026-07-28+ | v2 |
Get the design-system contract (tokens, motion, acoustic, takt, cadence)
Get the llms-full.txt agent brief (comprehensive)
Get the llms.txt agent brief
Get the full 23-package catalog (versions, URLs, statuses)
Get the SKILL.md agent-skill-format export
Fetch a URL's HTML + CSS, extract tokens, run 42-item contract verification checklist
Validate a DTCG 2025.10 design token file (20 conformance checks)
No error handling or recovery guidance documented. Tools that fetch external URLs (fetch_page_css, score_url, detect_drift, etc.) do not specify what happens on timeout, 404, network error, or invalid content. LLMs have no guidance on whether to retry, fall back to a different tool, or ask the user.
Tool descriptions lack context on when to use each tool vs alternatives. Multiple tools return metadata or contracts (get_design_system_contract, get_llms_txt, get_llms_full_txt, get_agent_json, get_skill_md) but their descriptions do not distinguish when to call each one or what use case each addresses. An LLM cannot reliably pick the right tool.
Input schema completeness varies. Tools like fetch_page_css and extract_root_tokens have minimal parameter descriptions; tools like get_contract_section have a parameter description but the enum or constraint set is not visible (should list valid section names: colors, motion, acoustic, etc.). Without enums, LLMs guess at valid values.