uxloom
OfficialServer 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.
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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