Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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.

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
}

Tools

Functions exposed to the LLM to take actions

NameDescription
project_initA

Create a new UXLoom project file (uxloom.project.json). Run once per product.

brief_startA

Start a design brief. Returns a structured questionnaire. Answer every question you can yourself — from the provided context document (PRD, spec) first, then conversation context; only relay questions marked askHuman:true to the user. Then call brief_answer.

brief_answerA

Submit brief answers. Unanswered fields take researched defaults and are recorded in the assumption ledger (auditable, reversible).

journey_defineA

Add or replace a journey (a state machine: states reference screens, events move between states). Screens referenced here must be registered via screen_register before project_validate passes.

screen_registerB

Add or replace a screen: its intent, requiredStates (the contract), designedStates (progress), and components with colors/labels/target sizes for the critics.

project_importA

Replace the whole project in one call: journeys and screens together. Prefer this over many journey_define/screen_register calls when registering a complete or large design. Validates the full document; unknown fields are rejected.

project_exportA

Return the complete current project document (for inspection, backup, or transformation before a project_import).

palette_checkA

Check a design system's color pairs against WCAG 2.2 AA (4.5:1) before any screens exist. Reports each pair's exact ratio, pass/fail, and thin-margin passes (under 5.0:1) that one shade lighter would break.

design_reviewA

One iterative design-review round (max 3 per project — enforced). Computes validation + rationale coverage, persists the round with deltas to .reviews.json, and returns a structured rubric to critique the design against: completeness, evidence, consistency, market fit, accessibility, honesty. Address the rubric, improve the design, then call again. Round 4 is refused: present results to the user instead.

comments_listA

Reviewer comments from the preview, with lifecycle status. Comments the reviewer clicked "→ agent" on are ASSIGNED — they are your work queue: call comment_context for each (assigned first, then open), make the change, then comment_resolve. Check this at session start and after every validation run.

comment_contextA

The full work packet for one reviewer comment: the comment, the exact layout block its pin lands on, the complete screen definition (contract, components, layout, rationale, exemptions), every journey state referencing that screen with its transitions, and the current validation findings scoped to that screen. Use it to address the comment precisely, then call comment_resolve.

comment_resolveA

Resolve a reviewer comment after addressing it. The resolution note is shown to the reviewer and persisted; the pin clears live in every open preview. Never resolve without actually making the change.

project_auditA

Audit the implementation against the design contract (drift detection). Static tiers: the uxloom.map.json screen registry and data-ux-screen/data-ux-state markers in source. Returns per-state verdicts (implemented with file:line evidence / unimplemented / unproven) and findings with fixes. When implementing screens from the contract, emit data-ux-state markers so the code stays self-auditing.

design_auditA

Reverse bridge (RFC 0007): audit a design export against the contract. Point it at a Figma/Penpot SVG or JSON export, a folder of them, or a uxloom --manifest index.json. Recovers screen×state from frame names (grammar " / ", or the manifest) and reports which required screens/states have no frame: design-screen-unmapped, design-state-missing, design-frame-unmapped. Optional scaffold writes a draft {screens} fragment for frames not yet in the contract. Deterministic, zero-coupling — no Figma/Penpot API.

project_validateA

Run every critic: journey completeness (unreachable states, dead ends, broken transitions), state coverage, WCAG contrast, touch targets, text expansion — plus fragment-merge errors and open reviewer comments from the preview. Honors uxloom.config.json thresholds. Iterate until errors = 0 and reviewer comments are addressed.

screen_critiqueB

Findings scoped to a single screen. Use during iteration on one screen.

coverage_reportB

The demo number: screens delivered vs. states the journeys actually need. Returns per-screen coverage and the missing-state list.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/uxloom-dev/uxloom'

If you have feedback or need assistance with the MCP directory API, please join our Discord server