ds-mcp-server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DS_TOKENS_DIR | No | Directory containing DTCG token files. Defaults to `tokens`. Equivalent to the server option `--tokens <dir>`. |
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_tokensA | Find design tokens by intent or name, for example 'muted text', 'control radius' or 'danger'. Use it before writing any color, spacing, radius or font value. Returns ranked tokens with their CSS custom property, description, deprecation status and resolved value per brand and mode. Semantic tokens rank above primitives; deprecated tokens rank last. |
| resolve_tokenA | Get the final value of one token for a given brand and mode, with the alias chain that produced it (for example color.fg.default -> color.neutral.900). Accepts a dot path, a CSS custom property or var(). Use it to explain a value or to check what a token becomes in dark mode. |
| find_token_for_valueA | Given a hard-coded value (#1a73e8, rgb(...), 16px, 1rem), return the tokens that carry it: exact matches first (semantic before primitive), then the perceptually nearest colors or nearest dimensions. Use it whenever code or a design contains a literal value, to replace it with a token. |
| lint_namingA | Check proposed token names against the naming grammar category.role.variant[.state]: lowercase kebab segments, known category, intent words instead of CSS properties (inset, not padding), state last, no brand or mode in the name. Returns violations and a corrected name when one can be derived. Call it before proposing a token. |
| audit_cssA | Audit a CSS snippet: reports hard-coded colors and dimensions (with the token to use instead), usages of deprecated tokens (with their replacement) and references to tokens that do not exist. Returns ok=false when there is at least one error. Use it to review generated or legacy CSS. |
| arbitrate_semverA | Given the token changes of a release (added, removed, renamed, value-changed, deprecated), return the required version bump (major, minor, patch) with a reason per change, and warnings when a token is removed without having been deprecated first. Use it to prepare a release or review a change set. |
| propose_tokenA | Prepare the addition of a token. Validates the name (lint_naming), collisions, the scope and the value (aliases must exist and have the same type), then returns a preview: the target file, a JSON Patch and a unified diff. Nothing is written unless confirm is true AND the server was started with writes allowed. Default to a preview and let a human review it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 7 tools
Each tool targets a distinct operation: intent/name search (search_tokens), single-token resolution (resolve_token), reverse lookup from a literal value (find_token_for_value), naming validation, CSS auditing, semver arbitration, and token proposal. The three token-lookup tools could superficially look similar, but their descriptions make the input types (intent phrase vs dot path vs literal value) unambiguous.
All seven tools follow a strict snake_case verb_noun pattern (search_tokens, resolve_token, find_token_for_value, lint_naming, audit_css, arbitrate_semver, propose_token). Verbs are meaningful and consistently chosen, with no camelCase or stylistic mixing.
Seven tools is well-scoped for a design-token governance server; each covers a distinct phase (discover, resolve, validate, audit, version, propose). No tool feels redundant or like padding.
The surface covers discovery, resolution, reverse lookup, validation, auditing, semver, and additive proposals well. Gaps remain around modifying or deleting existing tokens (rename/remove are only analyzed, not executed), but agents can work around this via propose_token and arbitrate_semver.