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, tokens, runtime APIs and migration changes. Use when you know what you need but not where it lives.

get_behaviorA

Complete public behavior API, including exact TypeScript declarations and supporting types. Filter by component id or exported API name; omit id for the full catalogue. Includes automatic selectors, manual initialization, cleanup, events and application responsibilities.

get_migration_guideA

Full canonical v2-to-v3 migration plan, rollout/rollback guidance, behavior changes, compatibility baseline and optional legacy geometry CSS. componentId filters behavior changes while preserving global migration requirements.

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_integrationB

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
behaviorsAll public runtime APIs, supporting types and lifecycle contracts.
migrationFull migration plan, behavior changes, compatibility baseline and bridge CSS.
componentsComplete component specifications and implementation contracts.
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.8/5.0

Scored across 21 tools

Disambiguation4/5

Most tools target clearly distinct resources: specs vs. code (get_component vs. get_component_code), single-pair vs. whole-theme contrast (check_contrast vs. audit_theme), and markup vs. integration validation. A few token tools (get_tokens, export_tokens, suggest_token, get_primitives) sit close together, but the descriptions differentiate them well.

Naming Consistency4/5

Strong and predictable get_<noun> pattern across the majority of tools, with coherent list_/validate_/suggest_/export_ prefixes for the non-retrieval operations. Minor deviations: 'search' is a bare verb without a noun, and validation-type tools use three different verbs (validate_, check_, audit_).

Tool Count4/5

21 tools is on the heavy side but the design-system domain genuinely spans discovery, components, foundations, tokens, primitives, layouts, patterns, migration, validation, and setup. Nearly every tool earns its place with a distinct artefact or operation.

Completeness5/5

Comprehensive lifecycle coverage: discovery (get_overview, search), specifications, code, tokens and primitives, foundations, patterns, layouts, migration guidance, validation, contrast auditing, setup, and exports. No obvious dead ends for an agent building or maintaining a Sekura interface.

Maintenance

ActivityActive
ResponsivenessNo issues