Public assessment

HalidSaglam/saglitzdesign-mcp (saglitzdesign-mcp)

saglitzdesign-mcp · v0.17.0 · scanned Aug 3, 2026

What changed in the harness

Selection accuracy 100→100, token cost down 5%, unconfirmed writes 100%→100%.

Category breakdown

Where the score comes from.

Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.

01Safety

30.0 / 30

30.0 out of 30

02Legibility

23.3 / 30

23.3 out of 30

03Economics

15.3 / 20

15.3 out of 20

04Discoverability

15.6 / 20

15.6 out of 20

Highest-impact fix

Estimated gain +1 point

Rewrite 9 underspecified tool descriptions

State each tool's behavior, explain every parameter, and declare return semantics, prioritizing tools exercised by failed selection tasks.

Description evidence

Defects and rewrites.

9 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.

Tool	Defect types	Suggested rewrite
`design_review_checklist`	no_return_description	Generate and return a structured design-review checklist for a project type (mobile app, website, landing page, dashboard), assembled from the knowledge base: for each area it lists the key rules and anti-patterns to check. Use it to audit an existing design or as acceptance criteria for a new one.
`get_design_roadmap`	no_return_description	Return the SaglitzDesign roadmap for a project type (website, landing page, iOS app, Android app, macOS app, SaaS web app): a phased, expert design process in which each phase lists its goal and the exact knowledge-base docs to consult. Use this FIRST when starting any design project, then fetch the phase docs as you reach them.
`knowledge_freshness`	no_return_description	Return a freshness report for each knowledge document: its age since last verification compared with its category's staleness threshold. Use this to decide which docs need re-research; the refresh workflow is documented in the repo's /refresh-knowledge command.
`get_component_recipe`	no_return_description	Return production-ready, accessible reference CODE for a UI component in a chosen stack (react-tailwind, html-css, swiftui, compose) — not advice, actual copy-paste code with all states, ARIA/accessibility, keyboard support and correct motion, grounded in the SaglitzDesign specs. Use when you need to actually build a button, input, modal, toast, card, switch, tabs, empty-state, or list-row. Pair with get_component_guidance (the design rationale) and generate_design_tokens (the theme).
`fix_contrast`	no_return_description	Repair a failing color pair: given a foreground and background hex, return the NEAREST accessible color (hue & saturation preserved, lightness nudged) that meets the WCAG 2.2 target — not just a pass/fail report. Use when audit_accessibility flags a pair and you need the corrected value to ship. For a full pass/fail audit use audit_accessibility; to build a whole palette use generate_color_system.
`generate_elevation_system`	no_return_description	Return a cohesive elevation / box-shadow ramp (layered ambient + direct light) with semantic level names (flat…modal), emitted as CSS custom properties and a Tailwind @theme block, plus dark-mode guidance. Deterministic. Use one shadow token per level instead of hand-tuning shadows per component.
`generate_motion`	no_return_description	Return a motion system: easing tokens (decelerate/accelerate/standard/spring as cubic-beziers), duration tokens, and ready-to-paste keyframe animations (fade-in, slide-up, scale-in, spring-pop, shimmer) emitted as CSS, Framer Motion, or SwiftUI code — grounded in the animation-craft rules (ease-out on enter, small distances, never scale(0), honor reduced-motion). Deterministic real code.
`create_design_system`	no_return_description	THE one-call foundation. Return a complete, coherent design-system starter by combining a brand color, a product vibe, and a platform: accessibility-verified color (light+dark), a matched font pairing, an icon library, a modular type scale, an elevation ramp, ready-to-paste design tokens (CSS/Tailwind or SwiftUI/Compose), the components to build, and a build checklist — all generated to work together. Use this FIRST when someone says 'design/build me a website/app' to lay the foundation, then get_component_recipe for each component and get_design_roadmap for the full process.
`generate_layout_system`	no_return_description	Return the layout foundation the other generators leave out: breakpoints (with what changes at each), container max-widths, edge padding, a column grid, an intrinsic auto-fit card grid, container queries, and a fluid section-rhythm scale — emitted as CSS custom properties and a Tailwind v4 @theme block, plus the rules that matter more than the numbers (design narrow-first, cap the measure at 45–75ch, prefer intrinsic layout to media queries). Deterministic real code. Pair with generate_type_scale and generate_design_tokens.

Selection evidence

Confusable tool pairs.

38 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.

Tool A	Tool B	Confidence	Why they collide
`create_design_system`	`audit_design_system`	medium	Both share 'design system', and a task like 'evaluate my current design system' could push an agent toward create_design_system (the 'first' tool) when audit_design_system is the correct match; typical design-system tasks are ambiguous between building and auditing.
`generate_color_system`	`generate_elevation_system`	low	Both start with 'generate' and end with 'system' and emit CSS/Tailwind themes, but color vs elevation are distinct enough inputs/outputs that a task asking for 'a color ramp' or 'shadow ramp' would resolve correctly.
`generate_color_system`	`generate_layout_system`	low	Shared 'generate' + 'system' tokens with clear thematic intent; 'colors' vs 'layout' are semantically distinct, so low plausible confusion.
`generate_design_tokens`	`import_design_tokens`	high	Near-identical names and nearly identical schemas (colors/formats/name vs source/formats/name). A task like 'get my theme into compilable tokens' or 'convert these tokens' could pull the wrong verb — generate creates from scratch, import reads existing input, and users frequently phrase import tasks as 'generate tokens from my CSS'.
`generate_elevation_system`	`generate_layout_system`	low	Both generate to CSS/Tailwind with similar properties, but elevation (shadows) vs layout (grids/breakpoints) are distinct; however a generic 'generate my system foundations' task could conflate them. Low-medium overall.
`get_component_guidance`	`get_component_recipe`	high	Both are 'get component ...' with near-identical inputs (component + platform). 'Give me a button I can use' is genuinely ambiguous between guidance (design rationale/specs) and recipe (copy-paste code); descriptions even cross-reference each other, and users frequently ask for components without clarifying code vs guidance.
`get_design_doc`	`get_design_examples`	low	Both 'get' + 'design' with overlap on web/platform, but one fetches a doc by id while the other retrieves app screenshots; lexical and semantic distance is enough for a user query to resolve.
`get_design_doc`	`get_design_language`	medium	Both fetch full reference documents ('full document', 'full reference document'); a task like 'give me the full Material design spec' is ambiguous between get_design_doc(id=material-3-ish) and get_design_language('material-3'), since the doc tool suggests IDs like 'material-3' in its description.
`get_design_doc`	`get_design_roadmap`	low	Shared 'design'/'get' tokens are thin; doc reads a knowledge doc, roadmap plans phases — meaningfully distinct.
`get_design_language`	`compare_design_languages`	medium	Both surface platform design-language content; a task like 'how do iOS and Android handle navigation' could trigger compare_design_languages, but a query like 'tell me about Material 3' or 'iOS design conventions' might lure an agent into get_design_language for one language when a comparison across platforms was intended, and vice versa.
`get_design_language`	`get_design_examples`	low	Distinct: reference spec vs curated screenshot examples; low same-token overlap beyond 'design/get/fetch'.
`get_design_language`	`get_design_roadmap`	low	Fetching a platform reference vs a phased project roadmap; an agent would pick the right one from project-scope vs platform-scope phrasing.
`get_design_roadmap`	`get_design_examples`	low	Shared 'design/get/website' tokens do little; roadmap is process planning, examples are screenshots — not confusable.
`list_design_knowledge`	`search_design_knowledge`	medium	Both operate on the same knowledge base with overlapping category/platform filters; a query like 'find docs about dark mode' or 'what do you have on pricing pages' is ambiguous between browsing the whole index (list) and querying for matches (search), and users don't always distinguish 'list what's available' from 'search for something'.
`audit_accessibility`	`audit_design_system`	low	Both 'audit' with color/size/ui overlap, but one is deterministic WCAG/tap-size checks while the other counts tokens in code; a task named 'audit accessibility' is not likely to hit the design-system audit.
`audit_accessibility`	`audit_ux_copy`	low	Just shared 'audit'/'ui'; accessibility vs copy are distinct audit domains.
`design_lint`	`audit_design_system`	medium	Both analyze pasted CSS/front-end code for design issues (colors, radii, tokens, !important) and their descriptions explicitly cross-reference each other as complements. A task like 'check this stylesheet for messy colors' could plausibly select either, since audit takes whole stylesheets while design_lint takes snippets of the same kinds of code.
`design_lint`	`compare_design_languages`	low	Only shared 'design' plus thin color/icon tokens; linting code vs comparing platform conventions are not confusable.
`design_lint`	`create_design_system`	low	Lint an inherited snippet vs scaffold a system; no real ambiguity.
`design_lint`	`import_design_tokens`	low	Both ingest CSS/Tailwind text, but import parses tokens and design_lint flags anti-patterns; descriptions keep them distinct.
`generate_color_system`	`generate_motion`	low	Only 'generate/scale/token' shared; color palette vs animation system differ clearly.
`generate_design_tokens`	`generate_motion`	low	Shared token/scale output vocabulary but different output kinds (design tokens vs animations) and 'generate' is too generic a hook.
`generate_elevation_system`	`generate_motion`	low	Both emit CSS keyframes/shadows but operate on different systems; motion vs shadow asks are distinct.
`generate_motion`	`generate_layout_system`	low	Shared 'generate/css/scale/rules' tokens; motion vs layout are far apart semantically.
`list_design_knowledge`	`knowledge_freshness`	low	Both touch the knowledge base but list/index vs freshness report are clearly distinct operations.
`search_design_knowledge`	`knowledge_freshness`	low	Searching content vs reporting staleness; only token 'knowledge' overlaps.
`suggest_font_pairing`	`suggest_icon_library`	medium	Identical 'suggest + intent/vibe/limit' schemas and both described as 'deterministic curated recommendations' for a product vibe; a task like 'what should I use for my modern SaaS vibe' is genuinely ambiguous between fonts and icons — the descriptions even instruct pairing them together, and users often say 'recommend me assets' without naming the category.
`get_component_guidance`	`get_design_examples`	medium	Both take a pattern/query (paywall, pricing, onboarding, empty state) and return real-world patterns; guidance returns docs in full while examples returns app/site screenshots. A request like 'give me best practices for a pricing section' or 'how do top apps do onboarding' could plausibly return the wrong member, since both are framed as pattern lookups.
`design_review_checklist`	`get_design_roadmap`	medium	Both are project-scoped (project_type) and cover the same project types (website, landing page, app); a task like 'plan the design work for my landing page' could trigger get_design_roadmap while design_review_checklist is acceptance-style, but an agent could pick the checklist when a roadmap was wanted or vice versa for a project-level ask.
`audit_design_system`	`compare_design_languages`	low	Shared 'color/design/how' tokens only; auditing code consistency vs comparing platform conventions aren't plausibly confusable.
`compare_design_languages`	`import_design_tokens`	low	Merely share 'design'; comparison vs token import diverge completely.
`create_design_system`	`generate_layout_system`	low	Both build 'foundations/systems', but create is the umbrella foundation call and generate_layout is one narrow part; a task explicitly asking for 'layout' resolves correctly.
`create_design_system`	`import_design_tokens`	low	Only shared 'design'; scaffolding from scratch vs converting existing tokens are clearly distinct.
`design_review_checklist`	`generate_design_tokens`	low	Shared 'design/type' tokens; reviewing vs generating are not confusable.
`generate_color_system`	`generate_type_scale`	low	Both 'generate + scale', but color palette vs typographic scale are distinct and their inputs (hex vs base/ratio) differ wildly.
`generate_design_tokens`	`generate_elevation_system`	medium	Both emit CSS custom properties and Tailwind @theme with same vocabulary (css, custom properties, semantic, tailwind, theme); a task like 'generate my theme tokens/shadow ramp' could blur them — generate_design_tokens includes the elevation values at a token level, and both producers emit 'CSS custom properties' artifacts, making 'make me theme CSS' ambiguous.
`get_design_doc`	`design_review_checklist`	low	Only shared 'design/knowledge/base'; fetching a doc vs generating a checklist diverge.
`list_design_knowledge`	`design_review_checklist`	low	Listing the index vs producing a review checklist share only broad 'design/knowledge/pattern' tokens.

Compare the field

One score is useful.
The evidence makes it actionable.

Back to the leaderboard