Skip to main content
Glama

Designesy

by io.github.LE-VAI

designesy_tokens_score

Validate a design token file against the W3C Design Tokens Community Group (DTCG) 2025.10 Final Community Group Report (the spec's first stable version, published Oct 28 2025 — Candidate Recommendation, considered stable). Returns 10 conformance checks (t01-t10) with PASS/FAIL/WARN. Use this to verify a tokens.json (or any DTCG token export) is structurally correct — $type/$value/$description present, structured colors (colorSpace + components rather than bare hex), a valid $schema pointer to designtokens.org, and correct dimension units. With 84% of teams now using design tokens (zeroheight Design Systems Report 2025, up from 56% in 2024) and the spec finally stable, every adopting team needs a validator. When NOT to use: for scoring a whole live site (not just its token file), use designesy_score. Executable — fetches the URL or parses the raw JSON you provide, runs 10 checks server-side. No browser needed. Returns JSON: { checks[{id (t01–t10), name, status (PASS/FAIL/WARN), detail}], valid, score }. Pass url to fetch a remote token file, or dtcg_file to validate an inline JSON string. Provide exactly one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoURL to a DTCG token file (JSON). The tool fetches and validates it.
dtcg_fileNoRaw DTCG token JSON string to validate (alternative to url).

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It discloses that the tool is executable, fetches a URL or parses inline JSON, runs 10 checks server-side, requires no browser, and returns a specific JSON structure. It could add more about side effects or error behavior, but the core behavior is well covered.

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

Conciseness2/5

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

The description is front-loaded and well organized, but it contains significant filler, especially the '84% of teams now using design tokens' marketing sentence and the repetitive spec-status framing. Several sentences could be cut without losing instructional value, so it is not appropriately sized for such a simple two-parameter tool.

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?

Despite having no output schema and no annotations, the description is complete enough for an agent to invoke the tool correctly. It covers purpose, input selection rules, execution behavior, and the exact JSON return contract. An agent knows what to pass, what will happen, and what shape the response will take.

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?

The schema already documents both parameters, and the description adds valuable nuance: url is for remote token files, dtcg_file is for inline JSON strings, and exactly one must be provided. This exclusivity and remote-vs-inline distinction goes beyond the schema's basic parameter descriptions.

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?

The description opens with a specific verb and resource: 'Validate a design token file against the W3C DTCG specification.' It further clarifies the concrete deliverable — 10 conformance checks (t01-t10) with PASS/FAIL/WARN — and explicitly distinguishes itself from the sibling designesy_score by stating that live-site scoring is not this tool's purpose.

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?

It gives clear when-to-use guidance: verify a tokens.json or DTCG token export for structural correctness. It also gives when-not-to-use guidance with a named alternative: 'for scoring a whole live site, use designesy_score.' The instruction to 'Provide exactly one' input source further guides invocation.

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

All Designesy toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly scoped purpose, and the extensive 'When NOT to use' notices cleanly separate the many scoring variants (e.g., score, drift, readiness, monitor, tokens, motion, a11y). Even similar informational endpoints (contract, skill, llms) are differentiated by format and use case. No two tools appear to do the same thing.

Naming Consistency5/5

All tools follow a consistent 'designesy_' prefix, and scoring tools uniformly append '_score' (e.g., drift_score, tokens_score, monitor_score). Non-score tools use descriptive noun suffixes (catalog, contract, report, guardrails). The pattern is predictable and uniform throughout.

Tool Count4/5

At 17 tools, the set is slightly above the ideal 3-15 range, but the breadth of the design-system intelligence domain justifies the count. Each scoring variant targets a different artifact (live URL, token file, Lottie, temporal drift) and the informational endpoints serve distinct formats. The tool count is heavy but not bloated.

Completeness5/5

The toolset covers the full assessment lifecycle: full audit (score), drift and temporal governance (drift_score, monitor_score), AI readiness (readiness_score), token and motion validation (tokens_score, motion_score), accessibility framework (a11y_score), diff (compare), composite report (report), guardrails generation, and multiple discovery formats (catalog, contract, skill_md, llms). No obvious dead ends exist; each tool leads to a usable artifact or clear next step.

Resources