Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
HOSTNoBind address0.0.0.0
PORTNoHTTP port8080
SEKURA_MCP_PATHNoMCP endpoint path/mcp
SEKURA_MCP_TRANSPORTNoTransport (stdio or http; default is stdio, http in Docker)stdio

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_overviewA

Start here. Returns the map of everything available: foundations, component catalogue, layout recipes, UX patterns, token groups and export formats, with the tool call needed to retrieve each.

searchA

Full-text search across components, foundations, patterns, layouts and tokens. Use when you know what you need but not where it lives.

get_foundationA

The reasoning behind the system: principles, colour, dark mode, responsive layout, typography, spacing, elevation, motion, accessibility, content and voice, iconography, density, internationalisation, data visualisation, theming. Read the relevant foundation before implementing in that area.

list_componentsB

The component catalogue, optionally filtered by category or status.

get_componentA

The complete spec for one component: anatomy, variants, sizes, states, props, tokens consumed, dark-mode behaviour, full accessibility contract (role, keyboard model, ARIA obligations, WCAG criteria, target size), content rules, and do/don't guidance.

get_component_codeA

Production code for a component in the requested framework. HTML returns reference markup with the required ARIA wiring; CSS returns the production stylesheet written against semantic tokens; framework options return editable reference recipes with native markup and lifecycle wiring. Inspect implementation metadata for dependencies and application responsibilities.

validate_integrationA

Check component markup, stylesheet dependencies, SVG symbols, ID references, initialization and declared application events. Returns structured findings and fixes; does not execute callbacks.

get_layoutA

A complete page blueprint: regions, responsive strategy, accessibility obligations, dark-mode notes, and paste-ready markup plus CSS. All recipes are flex-first and most contain no media query.

get_patternB

A recurring UX problem and the Sekura answer: the problem, the solution, the rules, the accessibility obligations, and the anti-patterns to avoid.

get_tokensA

Resolved token values. Filter by group, by name fragment, or return everything. Shows the value in every theme so dark-mode differences are visible side by side.

export_tokensA

Emit the full token set in a consumable format. Everything is generated from one source, so a primitive change propagates to every output.

get_primitivesA

The raw colour ramps behind the semantic layer. Use these to build new semantic tokens or to re-brand. Never reference a primitive from product code — it does not change between themes, so it will not adapt to dark mode.

suggest_tokenA

Describe what you are styling in plain words and get the semantic tokens that apply, with resolved values per theme and a note on why that token rather than a neighbour. Use this instead of guessing a token name or reaching for a hex value.

check_contrastA

WCAG 2.2 contrast ratio and pass/fail verdict for a foreground/background pair. Accepts hex values or Sekura token names — passing tokens resolves them for the chosen theme, including compositing translucent values over the page.

audit_themeA

Runs every contrast promise the design system makes against one theme or all four. This is the build gate — run it after any palette change. A pairing that is not declared here is not promised and must not be used to carry meaning.

validate_markupB

Checks HTML or CSS for the accessibility and design-system failures that actually ship: missing accessible names, unlabelled inputs, hard-coded colours that break in dark mode, flex containers that will overflow, positive tabindex, removed focus outlines, and misused live regions. Advisory — a clean result is not a certificate of accessibility.

get_setupA

Everything needed to start: the HTML scaffold, the pre-paint theme script (which must be inline and synchronous, or you get a flash of the wrong theme), the reset, the utility layer, the prose styles, and the theme control markup.

get_stylesheetA

The entire Sekura stylesheet as one file: tokens for all four themes and three densities, reset, prose, utilities, and every component. This is the single artefact needed to render any Sekura interface.

get_endpointsA

Absolute URLs for the stylesheet, token files, behaviours bundle and documentation site served by this instance. Use this instead of assuming paths: the server may be mounted under a path prefix, and only it knows what that prefix is.

Prompts

Interactive templates invoked by user choice

NameDescription
build-pageScaffold a page using the correct layout recipe, components and tokens.
review-uiAudit existing markup for design-system and accessibility compliance.
implement-dark-modeConvert an interface to support the Sekura dark theme correctly.

Resources

Contextual data attached and managed by the client

NameDescription
tokens-cssCSS custom properties for all four themes and three densities.
tokens-dtcgW3C Design Tokens Community Group JSON.
principlesThe seven decisions everything else follows from.
dark-modeHow dark mode differs from light, and the nine things that break silently.

TDQS

A3.7/5.0

Scored across 19 tools

Disambiguation4/5

Most tools cleanly map to distinct resources or actions, and the consistent prefixes make routing straightforward. The only real ambiguities are validate_integration vs validate_markup and get_tokens vs export_tokens, but their descriptions clarify the different intents.

Naming Consistency4/5

The set overwhelmingly follows a snake_case verb_noun pattern such as get_component, export_tokens, and audit_theme. The single bare verb 'search' is a minor deviation from an otherwise uniform convention.

Tool Count3/5

At 19 tools, the surface sits in the 16–25 range that feels heavy for agent navigation, even though the design-system domain is broad. The tools are largely non-redundant, so the count is borderline rather than excessive.

Completeness5/5

The server covers discovery, retrieval, validation, export, and integration setup with no obvious dead ends for a read-only design-system knowledge and validation server. get_overview ties the surface together and points to every relevant tool.

Maintenance

ActivityMaintained
ResponsivenessNo issues