Skip to main content
Glama

CSS to design tokens

css_to_dtcg
Read-only

Convert CSS custom properties into W3C design tokens (DTCG) JSON. Pass css (a :root block, a whole stylesheet, or a Tailwind v4 @theme block). Each variable is typed from its value and name (color, dimension in px or rem, duration, number, fontFamily, fontWeight, cubicBezier, shadow), grouped by type (color, spacing, radius, font-size, duration, and so on), and a var(--other) value becomes a {group.name} alias. The original CSS name and any dark value (from prefers-color-scheme: dark or a .dark or data-theme=dark selector) are kept in $extensions so dtcg_to_css can round-trip them. Variables that cannot be typed (calc(), clamp(), percentages, gradients, compound values, references to undefined variables) are listed with the reason instead of being guessed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "css": "<css>"
    },
    "name": "css_to_dtcg"
  }
}

Input Schema

NameRequiredDescriptionDefault
cssYesCSS with custom properties. Free up to 100,000 characters; Pro up to 2,000,000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already mark it read-only and closed-world, and the description goes far beyond that: typing heuristics, grouping behavior, alias formation from var(), dark-value capture via prefers-color-scheme/.dark/data-theme, $extensions round-trip with dtcg_to_css, and precisely what happens to untypable values (reported with a reason rather than guessed). That last point is a real behavioral promise an agent needs.

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 the purpose, then the input, then output typing, then edge-case handling in a logical sequence. The parenthetical type list and example group names run slightly long, but every clause carries information.

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

Completeness4/5

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

Covers input shapes, output structure, typing rules, alias formation, metadata preservation, and failure mode. With no output schema, an agent might still want the exact top-level JSON shape (e.g. whether tokens sit under a $ value wrapper or a group root), but the essentials to call it correctly are present.

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 coverage is 100%, so the baseline is 3, but the description adds meaning the schema omits: what shapes of CSS are acceptable and that one block or an entire stylesheet both work. The character limits live in the schema, so no need to repeat them.

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 precise verb+resource conversion: CSS custom properties → W3C DTCG design token JSON. It is immediately distinguishable from siblings like extract_design_tokens and dtcg_to_css, and names its inverse explicitly.

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

Usage Guidelines4/5

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

Acceptable input forms are enumerated (:root block, whole stylesheet, Tailwind v4 @theme block), which effectively defines when this tool applies, and the round-trip mention with dtcg_to_css gives the reverse alternative. No explicit 'do not use for X' exclusions, but the input contract is clear.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources