kodza
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.
Kodza is a free library of UI components and effects in plain HTML, CSS and vanilla JS (no framework, no build) for any site: a plain page, WordPress, Shopify, React or a Claude artifact. search_components finds them by what they do or look like; get_component returns one: its HTML, CSS and JS exactly as kodza.dev copies them, also as files, its API, keys, dark-mode values and install notes per target. Guide: https://kodza.dev/docs/. A site makes them its own, no edit to their CSS or JS:
Shared variables on :root apply to every component. Colours: --kz-color-ink (text, icons, rules, shades), --kz-color-paper (cards, fields, panels, menus), --kz-color-page (full-width backgrounds); optional: --kz-color-accent, --kz-color-on-accent, --kz-color-error. Type: --kz-font-display, --kz-font-label, --kz-font-mono. Corners: --kz-radius-scale, --kz-radius-pill. Fields: --kz-field-width. Page: --kz-page-width, --kz-page-gutter (one column for header, sections, footer and your containers). Pace: --kz-motion-scale (0: no motion). A site's palette is these, not each component's own colour variables. Unset, nothing changes; get_component names those each reads.
The CSS ends with a theme guard (the :not(#) lines), which keeps display and position on the root: a wrapper element around it moves or hides it. A page rule on a component's class loses to the guard on what it holds unless its selector ends with :not(#); a rule on an inner element (kodza-x__y) is the last resort.
Texts a script writes (a placeholder, a "Done" button) are data-text-* attributes on the root, under API as Texts with English defaults: a site in another language sets each one and translates the HTML.
A date or time field has none typed in its markup, the demo's included: its min, max, value and slots are computed by the page's script at load.
Components never style html: a one-page with a sticky header sets html { scroll-padding-top: }, and html { scroll-behavior: smooth } inside @media (prefers-reduced-motion: no-preference). In more detail: It covers buttons, links, text effects, sliders and galleries, cards, navigation, scroll effects, preloaders and page transitions, forms, overlays, feedback and data display. In what get_component returns, the theme guard is generated and keeps a site's own CSS from restyling the component's buttons and fields. The CSS and JS are also files at the URLs of its Files section, with their download commands; with inline: false the Code section leaves that CSS and JS out and keeps the HTML. The API lists the --kz-* CSS variables with their defaults, the modifier classes, the data attributes, the data-text-* texts and the events. The install notes cover a plain page, a Claude artifact, WordPress, Shopify and React (target keeps one of them). The colours: --kz-color-ink is the ink (text, icons, rules, and the shades mixed from it), --kz-color-paper the surfaces set on the page (cards, fields, panels, floating menus), --kz-color-page the full-width backgrounds (headers, footers, sections, curtains), --kz-color-accent the solid fills (a filled button, a selection, a badge, an active dot; falls back to the ink), --kz-color-on-accent the text on those fills (falls back to the paper) and --kz-color-error a field's error, always an icon and a message (falls back to the component's ink). Shadows, veils and text laid over an image keep their own colours. The type variables come with their weight, scale or size, tracking, case and leading. The page: headers, sections and footers line up on one column, --kz-page-width (the text edge, 1440px by default) with --kz-page-gutter (the side margin on narrower screens, clamp(16px, 4vw, 40px)); a page's own containers take the same two (max-width: var(--kz-page-width, 1440px), side padding var(--kz-page-gutter, clamp(16px, 4vw, 40px))) so that everything shares one edge. A component's own colour variables (--kz--) stay for the one component that departs from the palette. The theme guard also holds the margin of a root that is a button; other margins and float on a root stay the page's. Restyling goes through the API first: the --kz- variables, modifiers and attributes do it without a page rule. A page rule that has to win reads .kodza-x__y:not(#) { … }, a rule that wins without :not(#) does not need it, and a rule on an inner element is the last resort because a later version of the component can change its markup. A sticky component sticks only inside its parent, so a wrapper of its own height keeps it from sticking. Each component is checked for horizontal overflow on a 375 px wide screen, in its own demo; a page built from components is not, so an overflow there, such as a component that a page rule failed to hide, appears only once that page is open at that width. A Claude artifact (claude.ai) loads no images or files from other sites, and the artifact install notes say what that changes. One copy of a component's JS serves every instance on a page; content added after the page loads starts with a kodza:init event and stops with kodza:destroy, as the install notes show. The install notes of each sticky header give the height for scroll-padding-top. The texts a script writes also include an "x of y free" count or a label read aloud; a component that lists no Texts has none to set. Dates are computed from the current date, otherwise the page is wrong the day after it ships.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_componentsA | Find Kodza UI components (plain HTML/CSS/vanilla JS) by what they do or look like, e.g. "button fill hover", "image slider", "sticky header", "date picker". An empty query lists a whole category. Returns the slugs get_component takes. |
| get_componentA | The full code of one Kodza component (HTML, CSS and, when it has one, vanilla JS), its API (CSS variables with defaults, modifier classes, data attributes, events), what each key does when it takes the keyboard, its dark-mode values and its install notes. Its CSS and JS are also available as files at the URLs listed in its Files section; with inline: false, the answer leaves them out of the Code section. target narrows the install notes to one stack. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| build_page | Build a page or a section of a site from Kodza components, then list the ones used with their demos. |
| replace_element | Swap an element of your site (a button, the menu, a form field…) for the Kodza component that does the job, keeping its content and behaviour. |
| find_component | See what Kodza has for a need, with a demo link for each, before any code. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
search_components is clearly for discovery and returns slugs, while get_component retrieves full details for one slug. Their purposes are complementary and non-overlapping, so an agent can easily choose the right tool.
Both tools follow a consistent snake_case verb_noun pattern: search_components and get_component. The naming is predictable and readable.
The server is intentionally minimal, but two tools is thin for a component library interface. The search/get split is coherent, though additional browse or category tools could reduce reliance on search nuances.
The surface covers discovery and full component retrieval, including code, API, keyboard behavior, dark-mode values, and install notes. Minor gaps exist around explicit category browsing and file-focused retrieval, but the core read-only workflow is covered.