melta-ds-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_tokenA | Get a design token by dot-path. Returns the token object with its value and class mapping. |
| get_componentA | Get component metadata including variants, sizes, accessibility requirements, HTML sample, per-state specs (stateSpecs: disabled/loading/open/empty etc. — each with delta class strings + aria changes), and anatomy parts (overlay/container/th etc. with element/roles/class). Prefer these structured fields over inferring states from the HTML sample. |
| check_ruleB | Check class strings against this design system's prohibition rules. Returns violations with reasons and alternatives. |
| check_htmlA | Lint a full HTML/JSX source against melta-ui rules — the same checks as CI and the PostToolUse hook (class rules + html-attr rules + composition rules for HTML). Use this AFTER generating UI code to self-verify before presenting it. Response always includes coverage info (manual rules cannot be auto-checked). |
| searchA | Search across tokens and components by keyword. Matches against names, values, class strings, and descriptions. Returns up to 20 results (truncated flag when more matched). |
| get_rulesA | Get melta-ui prohibition rules from rules.json (107 total). Use this to retrieve manual/contextual rules that check_rule cannot auto-detect. Supports filtering by category, severity, or detector. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Design Constitution (DESIGN.md) | Start here before UI work: brand identity, non-negotiable principles, Quick Reference, prohibited Top 10, and source-of-truth order |
| Design Tokens | Design tokens (colors, typography, spacing, etc.) |
| Components | All 40 component metadata (variants / sizes / a11y / class strings) |
| Prohibition Rules (all) | All 107 prohibition rules including manual ones (full SSOT for AI reference) |
| Prohibition Rules (auto-detectable subset) | Subset of rules that check_rule can auto-detect from Tailwind class strings |
TDQS
Scored across 6 tools
Most tools target distinct objects (get_component, get_token, search) with clear boundaries, but check_rule, check_html, and get_rules form a cluster around prohibition rules. The descriptions do distinguish them (apply to class strings vs. full HTML vs. retrieve raw rules), so an agent can reasonably select correctly.
Names mostly follow a verb_noun pattern (get_component, get_token, get_rules, check_rule, check_html), with only 'search' as a bare verb deviation. Still highly predictable and consistent in style.
Six tools is well-scoped for a design-system lookup and validation server. Each tool serves a distinct purpose (component metadata, tokens, search, three rule-checking variants) with no obvious filler.
The surface covers the core read-only lifecycle: discover (search), inspect (get_component/get_token), and validate (check_rule/check_html/get_rules). Only minor gaps exist, e.g. no explicit list-components or list-tokens endpoint, though search largely covers discovery.