basecoat-ui
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BASECOAT_PROJECT_ROOT | No | Overrides the launch directory to select the host application's DESIGN.md. It is not the MCP installation directory. This is overridden by --project-root. |
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
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_componentsA | Find up to 8 compact component summaries by intent and/or query (either field may be omitted). No matches returns an empty list; no markup is returned. |
| get_component_detailsA | Get one minimal component template, dependencies, and composition tips for Astro or HTML. Response is bounded below 2000 UTF-8 bytes. |
| validate_compositionA | Statically check HTML/Astro source for Basecoat migration errors, semantic rhythm, FSM bindings, missing scripts, nested cards, spacing and hierarchy issues. Pass |
| search_macro_blocksA | Search approved macro layout blocks by query, role, family, or tag. Optional design/page/slot context filters to slot-compatible roles. Returns summaries and immutable refs only; use cursors for more. |
| get_macro_blockB | Retrieve one section of a compiled macro block blueprint (manifest, structure, slots, ports, rules, dependencies, provenance). Follow next cursors until complete. Optional designId pins aliases to that session registry. |
| begin_designA | Create a persistent design session under the host project root. Pass designId, profile (alias or ref), operationId, and optional decisions. Pins and hash-verifies the packaged macro registry. Idempotent for the same operationId. Oversized optional receipt fields may be omitted with truncated:true after commit. |
| get_design_contextB | Read a focused design view: sessions (no designId), overview, decisions, graph, rules, focus, or next. Pin revision on first read; continuations must match. Does not create sessions. |
| apply_design_patchA | Apply one atomic list of design graph operations with expectedRevision and operationId. Replay with the same operationId returns the original receipt. A committed mutation always acknowledges success; oversized optional fields may be omitted with truncated:true. Does not write application source files. |
| validate_designA | Validate a design session (or one page) in draft or complete mode. Returns totals plus paginated diagnostics. A plan-ready graph is not proof of rendered correctness. |
| get_rhythm_rulesA | Read the effective semantic rhythm profile by family, including project-local overrides under a contained .basecoat/rhythm.json. Semantic IDs and approved implementation utilities are returned separately. Results are content-addressed and cursor-paginated; changed effective revisions invalidate prior cursors. |
| get_fsm_recipeB | Read finite FSM states, events, guards, actions, or transitions. Recipes are structural metadata, not executable runtime code. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| design-rhythm | Content hierarchy, spatial rhythm, density, typography, and composition constraints. |
| design-theming | Basecoat token contract, class-based dark mode with one resolver (basecoat.theme / themeMode), no-flash bootstrap, form control and autofill pitfalls. |
| framework-integration | Production integration (Astro, Next.js, Express/Node), Tailwind 4 setup, and framework-agnostic usage. |
| project-context | Read DESIGN.md from the explicitly configured host project root; bounded local data. |
TDQS
Scored across 11 tools
Each tool targets a distinct resource+action: component search/detail, macro search/detail, design session lifecycle, validation, rhythm rules, and FSM recipes. The only mild overlap is validate_composition vs validate_design, but descriptions clearly separate static source validation from design-session validation.
All tools use consistent snake_case with verb_noun patterns (search_, get_, validate_, apply_, begin_). Minor noun number differences (get_component_details vs get_macro_block) do not break predictability.
11 tools are well-scoped for a UI framework covering components, macros, design sessions, validation, and metadata. No tool appears redundant; each earns its place.
The surface covers discovery, detail retrieval, validation, design session creation/patching/reading, and auxiliary rules/recipes. Minor gaps exist: no explicit end/delete design session operation, and rhythm/FSM recipes are read-only with no update path, but core workflows are covered.