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

Upgrade to the current release from v2 or v3.0: full canonical plan, source-specific steps, rollout/rollback guidance, behavior changes, compatibility baseline and optional legacy geometry CSS. componentId filters behavior changes; fromVersion selects the upgrade source while preserving the complete guide.

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_tokensB

Emit tokens in a consumable format. Each format documents its supported scopes, projections and consumer verification obligations; CSS is the complete runtime token artifact.

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 for the rendered foreground/background pair. Supports hex, transparent, modern rgb() and token names. Composites background over an explicit opaque backdrop, or the disclosed theme base when omitted, then foreground over that background.

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_markupA

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.
migration-3.1-aliasCompatibility alias for the current migration guide.
migration-currentCurrent migration guide with v2, v3.0 and v3.1 upgrade paths.
migration-v3.0-currentUpgrade to the current version from v3.0.
migration-v3.1-currentUpgrade to the current version from v3.1.
migration-v3Upgrade path and compatibility baseline for v3.0 consumers.
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 have clearly distinct targets (catalogue vs single component vs code vs behaviour vs migration). A few clusters need the descriptions to disambiguate: get_tokens/export_tokens/get_primitives/suggest_token all touch tokens, and validate_markup vs validate_integration overlap on validation. The descriptions do a good job of explaining when to use each, so misselection is unlikely but possible.

Naming Consistency5/5

Names uniformly follow a snake_case verb_noun pattern (get_component, list_components, validate_markup, export_tokens, audit_theme, suggest_token, check_contrast). The only mild outlier is the bare 'search', which is idiomatic and unambiguous. No mixing of casing or style conventions.

Tool Count4/5

21 tools is on the heavy side but maps to a genuinely broad domain: discovery, components, foundations, tokens, code, patterns, layouts, validation, migration and setup. Each tool earns a distinguishable place, though a few token-related ones could conceivably be consolidated.

Completeness4/5

Coverage is strong for a read-only design-system surface: overview/discovery, component catalogue and specs, foundations, tokens, code and layout generation, contrast/theme/markup/integration validation, migration and endpoint discovery. Minor gaps like a changelog or version-history tool exist, but core agent workflows have no dead ends.

Maintenance

ActivityActive
ResponsivenessNo issues