css-is-awesome-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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_themesA | List all 24 shipped themes (boilerplate-dark, boilerplate-light, boilerplate, cupertino-dark, cupertino-light, cupertino, glass-dark, glass-light, glass, graphite-dark, graphite-light, graphite, press-dark, press-light, press, prism-dark, prism-light, prism, sketchbook-dark, sketchbook-light, sketchbook, terminal-dark, terminal-light, terminal). Eight families; each ships an unsuffixed parent carrying both modes via light-dark() plus pinned -light and -dark siblings (terminal is the exception — its unsuffixed file is dark-only). Every theme emits |
| get_themeA | Return one theme: declared token assignments, raw SCSS body, light-dark() support flag, and source path. Themes are authored through |
| search_themesC | Substring search across theme names, descriptions, and token values. |
| validate_themeA | Validate ANY theme CSS against cia's real token contract and WCAG contrast audit — the same check |
| theme_from_tokensA | Build a complete, validated cia theme.css from a design-tokens JSON — DTCG v2025.10 ({ $value, $type }, {aliases} resolved), a Tokens Studio for Figma export ({ value, type }, single or multi-set), or a flat { "--token": value } map. Format is auto-detected. Every REQUIRED contract token the file does not supply is inherited from a shipped base theme (default boilerplate) and listed in report.inherited, so the output is always contract-complete; unmapped paths are emitted verbatim and listed in report.unmapped, never dropped. Pass |
| get_token_mapA | The design-token → cia-token mapping that theme_from_tokens applies, as data. Without |
| list_mixinsA | List all 157 public @mixins across core, layout, animation, icons, generator, per-component and recipe sources. Filter by category (core/layout/animation/icons/generator/component/recipe) or component name. |
| get_mixinA | Return one mixin: signature, parameter list, doc comment, full body, source path + line range. |
| search_mixinsB | Substring search across mixin names, signatures, docs, and bodies. |
| list_functionsB | List all 26 public @functions (color, space, radius, shadow, font-size, z, etc.). Same shape as list_mixins. |
| get_functionA | Return one function: signature, parameters, doc, body, source location. |
| search_functionsB | Substring search across function names, signatures, docs, and bodies. |
| list_tokensA | List the CSS custom-property tokens in the theme contract (scripts/theme-contract.json): 127 required + 41 optional = 168 total. Categories: a11y, action, brand, code, fx, ink, interactive, lines, misc, motion, radius, semantic, shadow, space, surface, type, z-index. Spacing note: the NUMBERED scale --space-0…--space-9 is required and is what components read (cia.space(4) → var(--space-4)); the t-shirt names --space-2xs/xs/sm/md/lg/xl are optional aliases the library emits as var() references. Theme the numbered step, not the alias. Radius note: --radius-avatar/badge/button/card/input/modal were removed (nothing read them). The working per-component knobs are --btn-radius, --card-radius, --input-radius, --modal-radius, --badge-radius, --tag-radius, each cascading from a generic radius (e.g. --btn-radius: var(--radius-md, 0.25rem)). |
| get_tokenA | Return one token: category, required flag, sample values across all themes, and the list of mixins/functions that reference it. |
| search_tokensC | Substring search across token names and categories. |
| list_animationsA | List the animation vocabulary (fade-in, slide-up, scale-in, pop, pulse, shimmer, spin, wiggle, …), the speed keys (fast/normal/slow), the animate-on effects (lift/glow/press/fade), and the mixin signatures. |
| get_animationA | Return one animation slug → keyframe mapping with usage examples, or the animate/animate-on mixin record by name. |
| list_componentsA | List every component file under scss/components/ (accordion, buttons, copy-button, data, feedback, forms, navigation, overlay, stepper, tabs). |
| get_componentA | Return one component: description, all its public mixins (signature + summary + body), and the source path. |
| search_componentsC | Substring search across component names, descriptions, and their mixin names/signatures/docs/bodies. |
| list_recipesA | List recipes from scss/recipes/. Two kinds: markdown pattern recipes (kind:"md" — dialog, combobox, print-to-pdf: a pattern to follow in any framework, with category + complexity) and opt-in SCSS recipes (kind:"scss" — e.g. bare-tags, consumed via @use). |
| get_recipeA | Return one recipe: name, kind ("md" pattern recipe or "scss" import), category/complexity, usage, and full body (markdown for md recipes, SCSS for scss recipes). |
| read_llm_txtA | Return llm.txt — the canonical single-fetch summary for AI agents. |
| read_changelogA | Return CHANGELOG.md — full release history including breaking-change notes. |
| read_migrationA | Return MIGRATION.md — v0.7 → v0.8 migration guide (renames, removed features, breaking changes). |
| read_themingA | Return THEMING.md — theme authoring + override patterns. |
| read_agentsA | Return AGENTS.md — entry point for AI coding agents (rules, tiers, quick decisions). |
| read_contractA | Return CONTRACT.md — human-readable token contract. |
| read_three_tiersA | Return THREE-TIERS.md — the three authoring tiers (mixin / utility class / bare tag). |
| read_readmeA | Return README.md — top-level install + usage. |
| read_versioningA | Return VERSIONING.md — semver policy, deprecation lifecycle, and the Conventional Commits to changelog mapping. |
| assemble_promptA | Build a ready-to-paste context block for an LLM consuming cia. Intent picks the slice: "overview" | "mixin:" | "component:" | "theme:" | "tokens" | "animations" | "recipe:". |
| resolve_sizeA | Snap a design px value to cia's 4px geometric grid. Returns the step number, the SCSS call to emit (cia.grid(n) when exactly on grid; cia.px(value) when off-grid), the equivalent rem, and a human-readable note. AI agents: call this whenever you get a px value from a design tool (Figma, mockup, screenshot) and need to express it in cia code. NEVER write raw rem/px literals when a cia function applies. See /docs/composition for the full decision tree. |
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 33 tools
Every tool targets a distinct resource and action: list/get/search per entity type (themes, mixins, functions, tokens, components, recipes), with specialized tools for validation, building from tokens, and reading documentation. No two tools overlap in purpose, even within the same entity—get_theme returns a theme, validate_theme checks CSS, and theme_from_tokens generates from tokens.
Tool names follow a consistent verb_noun pattern using lowercase snake_case. Verbs like list, get, search, validate, read, assemble, and resolve are uniformly applied; plural nouns are used for list/search, singular for get. The pattern is predictable and immediately understandable.
With 33 tools, the count exceeds the typical 3–15 range, but the server covers a broad CSS framework with many distinct resource types (themes, mixins, functions, tokens, animations, components, recipes, docs). Each tool serves a unique purpose, and the high count is justified by the scope, though it borders on heavy.
The tool surface comprehensively covers the domain: theme operations (list, search, get, validate, build), introspection of mixins/functions/tokens/animations/components/recipes, documentation access, and utility helpers (assemble_prompt, resolve_size). No significant gaps exist for an information-retrieval and assistance MCP server.