Skip to main content
Glama
LE-VAI

Designesy

by LE-VAI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Score URL against contract

designesy_score
Read-onlyIdempotent

Audit a website or AI-generated UI against a design contract: scores 45 checks for tokens, motion, accessibility, typography, and copy, returning a numeric score, grade, and results.

Instructions

Score a live URL against the Designesy design contract with the deterministic 45-check verification engine at https://www.designesy.org/api/score. Returns a numeric score, a letter grade (A-F), and the check results. Use this to audit whether a website or AI-generated UI complies with a real design contract (tokens, motion, accessibility, cadence, takt, typography, copywriting). When NOT to use: for token-file validation only, use designesy_tokens_score; for a Lottie file, use designesy_motion_score; for a qualitative critique, use designesy_design_review. The engine fetches the URL server-side, extracts its CSS, and runs 45 checks. Results are cached ~24h server-side per URL and scope. Checks that need a live browser (Core Web Vitals, sound toggle, overflow) return MANUAL; the full audit (/api/score/audit) resolves them. Checks that do not apply to the site (no tokens, no buttons, no DESIGN.md) return SKIP (N/A). format selects the output. designesy (the default) returns JSON: { url, contract_version, summary { total, pass, fail, warn, skip, manual, score (0-1), score_percent (0-100), grade }, tokens_extracted, checks[{ id, item, category, status, detail }], note }. canonical returns the engine's review-findings.json schema JSON unchanged. review returns the engine's markdown report unchanged (coverage by category, a findings table of the FAIL and WARN checks, and a verdict). google returns the engine's @google/design.md-compatible JSON unchanged. scope sets the scoring scope: contract or universal. Omit it and the engine auto-detects: contract for designesy.org, universal for every other site. If the engine is unreachable, format designesy falls back to the offline engine: 27 of the 45 checks run locally, each mirroring the live engine's verdict, under the same scope. Its result adds engine (kind offline, the engine version it mirrors, and the checks it did not run) and scope, and its note says so. The other three formats return an error, because only the live engine produces them.

Input Schema

NameRequiredDescriptionDefault
urlNoURL to score. Defaults to https://www.designesy.org/ if not provided.
scopeNoScoring scope. contract: every check counts absence against the site. universal: optional features and Designesy-specific token checks return SKIP when absent. Omit to auto-detect: contract for designesy.org, universal for every other site.
formatNoOutput format. designesy (default): the native JSON. canonical: the review-findings.json schema. review: a markdown report. google: the @google/design.md-compatible JSON.designesy

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.13.8

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, openWorld); the description supplies genuinely additive behavior: server-side URL fetch plus CSS extraction, ~24h server-side caching per URL and scope, MANUAL status for browser-dependent checks with the /api/score/audit endpoint that resolves them, SKIP semantics for non-applicable checks, and a 27-of-45-check offline fallback that annotates its own result with engine/scope and degrades the non-default formats to errors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose, then exclusions, then behavior and output contracts — a logical order. It is long, and the fallback/format cross-product is explained at a level of detail some agents won't need, but every sentence carries operational information rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description assumes the full burden of describing returns and does so: the designesy JSON field tree (summary, checks, tokens_extracted, note), what each alternate format yields, the manual/skip statuses, and the fallback's added fields. An agent has everything needed to call it and interpret the response.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description goes beyond it: it explains that format changes the returned document structure (native JSON vs review-findings.json vs markdown vs @google/design.md), that scope auto-detects by host (contract for designesy.org, universal otherwise), and that in offline fallback only the default format succeeds while the other three error out. No syntax/size constraints or defaults beyond the schema are added, so it stops short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource+mechanism: 'Score a live URL against the Designesy design contract with the deterministic 45-check verification engine.' It names the exact endpoint and enumerates the check categories (tokens, motion, accessibility, cadence, takt, typography, copywriting), so it is unmistakable among the 16 siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Contains an explicit 'When NOT to use' block that routes to three named siblings by distinct condition (token-file validation → designesy_tokens_score, Lottie file → designesy_motion_score, qualitative critique → designesy_design_review). When-to-use is also stated directly ('audit whether a website or AI-generated UI complies').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools