Pixl is an MCP server that turns AI coding hosts into a guided mobile UI design tool, enforcing a locked design-system token contract and providing a local browser preview with a phone-frame screen gallery and draggable user-journey flow map.
Initialize the workspace: Set up the .pixl/ folder, boot the local browser preview at localhost:4321, and optionally open it automatically in your browser.
Check workspace status: Get a snapshot of the current state — initialization status, active design system, screen count, flow node count, and preview URL.
Browse and set a design system: List curated design-system presets, then select one (with optional overrides) or provide fully custom tokens (colors, typography, spacing, radius, shadows, breakpoints). This locks a token contract that all screens must follow.
Plan screens and user journey: Define an ordered list of screens (IDs, names, descriptions) and directed transitions between them, seeding both the screen plan and the flow map.
Generate and save screens: Submit full self-contained HTML for a screen; it is linted against the token contract — valid screens are saved and live-rendered in the gallery, invalid ones return specific violation feedback.
Lint screens without saving: Validate a screen's HTML against the token contract as a dry run, to catch violations before committing.
Update the flow canvas: Define or update the user-journey graph (nodes and directed edges with transition labels) rendered on the draggable flow canvas, preserving manually set node positions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pixl start a new mobile UI design project"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Open-source MCP server for designing mobile UIs. Pixl plugs into whatever AI coding host you already use (Claude Code, Cursor, …) and turns it into a guided mobile-UI design tool. Your host's model does the generating — Pixl supplies the taste it lacks: a locked design-system token contract, a linter that rejects off-standard output, and a local browser preview with a phone-frame gallery and a draggable user-journey flow map. Everything runs locally.
Status: v0.1, feature-complete — MCP server, workspace, live preview, design-system presets + token contract, screen generation with the taste linter, and the draggable user-journey flow canvas.
host (Claude Code / Cursor) ──MCP stdio──▶ pixl-mcp (Node/TS)
│ owns .pixl/ workspace, runs linter
▼
localhost:4321 Vite + React preview
├── Screen gallery (phone frames, live-reload)
└── Flow canvas (dotted bg, draggable)State lives in a .pixl/ folder in your project: tokens.json, design/*.md, screens/*.html, flow.json.
Related MCP server: Plumb (plumb-mcp)
Pixl auto-starts when your host connects: it creates the .pixl/ workspace, boots the preview, and opens localhost:4321 in your browser. No pixl_init call needed — just point your host at it and start asking for screens.
npx (recommended):
Cursor — ~/.cursor/mcp.json:
{ "mcpServers": { "pixl": { "command": "npx", "args": ["-y", "pixl-mcp"] } } }Claude Code:
claude mcp add pixl -- npx -y pixl-mcpDocker (no Node needed; fully isolated). -p 4321:4321 forwards the preview; the sh -c wrapper reaps any prior container so relaunches don't clash on the port:
{
"mcpServers": {
"pixl": {
"command": "sh",
"args": [
"-c",
"docker rm -f pixl-mcp >/dev/null 2>&1; exec docker run --rm -i --name pixl-mcp -p 4321:4321 -v \"$PWD\":/work -w /work pixl-mcp"
]
}
}
}Build the image first with docker build -t pixl-mcp . (or pull it once published).
npm install --include=dev # this machine has npm omit=dev set globally
npm run build # compile the server to dist/
npm run typecheck
npx vitest run # linter unit tests (pass/fail fixtures)
node scripts/smoke.mjs # workspace + preview API end-to-end
node scripts/mcp-smoke.mjs # drives the server as a real MCP client
node scripts/phase2-smoke.mjs # design system + screen plan
node scripts/phase3-smoke.mjs # write/lint screen: reject bad, accept fixed
node scripts/phase4-smoke.mjs # flow graph + drag-persist round-tripClaude Code:
npm install --include=dev && npm run build
claude mcp add pixl -- node /absolute/path/to/pixl-mcp/dist/index.jsThe preview auto-starts and opens localhost:4321 — then ask your assistant to set a design system and generate screens.
Tool | Purpose |
| Re-open the preview / fetch its URL (auto-runs on startup — you don't call it) |
| Report workspace state |
| Design system + screen plan |
| Generate + lint screens |
| User-journey flow graph |
MIT.
Create the .pixl workspace in the current project, boot the local browser preview, and open it. Call this first. Returns the preview URL to relay to the user.
| Name | Required | Description | Default |
|---|---|---|---|
| openBrowser | No | Open the preview in the default browser automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: creates workspace, boots preview, opens browser, returns URL. No annotations exist, so description carries full burden; it covers the main actions but omits potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the essential action, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an initialization tool with no output schema, the description covers the main actions and states the return value (preview URL). It is complete enough for an agent to use without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single boolean parameter with a description. The tool description adds no additional parameter semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Create, boot, open) and resource (.pixl workspace, browser preview). It distinguishes itself from sibling tools by being the initialization step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this first,' providing clear usage guidance. Lacks explicit when-not-to-use or alternatives, but the instruction is strong enough for a setup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lint provided HTML against the active token contract WITHOUT saving. Use to check a draft before committing it with pixl_write_screen.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Full screen HTML to lint. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Key behavior 'WITHOUT saving' is disclosed. Although no annotations exist, the description covers the primary behavioral aspect for a lint tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema), the description provides all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the single parameter fully. Description adds little beyond 'full screen', so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lints HTML against a token contract without saving, and explicitly distinguishes from pixl_write_screen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use for checking a draft before committing, and names the sibling tool for saving.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the curated design-system presets. Show these to the user and let them pick one (by id) before calling pixl_set_design_system.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It indicates a read-only listing action with no destructive behavior. However, it does not disclose return format, auth needs, or rate limits, which are minimal concerns for a trivial tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly concise, and front-loads the action. Every sentence provides essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description is fully complete. It tells the agent exactly what to do (list, show, let user pick) and how it fits with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no parameter info, but baseline for 0 parameters is 4. No further semantic help needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists curated design-system presets, with a specific verb ('List') and resource ('design-system presets'). It distinguishes from sibling tool pixl_set_design_system by indicating the order of use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to show presets to the user and let them pick before calling pixl_set_design_system, providing clear context for when to use this tool. No exclusions are needed given its straightforward role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record the screen list and the user journey between them. Writes screens.md and seeds the flow map. Do this after the design system is set and before generating screens.
| Name | Required | Description | Default |
|---|---|---|---|
| journey | No | Directed transitions between screen ids. | |
| screens | Yes | Ordered list of screens. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses side effects: 'Writes screens.md and seeds the flow map.' However, it does not specify whether these writes are overwrites, or if there are any destructive implications. Some behavioral traits are disclosed, but not comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the primary action and then provide workflow placement. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers the core purpose, timing, and outputs. Minor gaps: it doesn't explain what 'seeds the flow map' means or prerequisites for the design system. Overall, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it says 'Record the screen list and the user journey between them,' which maps to the two parameters. No additional meaning or format details are provided that aren't already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Record the screen list and the user journey between them.' It names outputs (screens.md, flow map) and places the tool in a workflow relative to siblings (after design system, before generating screens). This clearly distinguishes it from sibling tools like pixl_set_flow or pixl_write_screen.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit timing: 'Do this after the design system is set and before generating screens.' This provides clear context for when to use the tool. It does not explicitly list alternatives or when not to use, but the sibling list and context signals enable comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lock the design system. Pass a presetId (from pixl_list_presets) with optional overrides, OR fully custom tokens. Writes tokens.json + design/*.md and returns the TOKEN CONTRACT — obey it for every screen you generate.
| Name | Required | Description | Default |
|---|---|---|---|
| presetId | No | Preset id, e.g. 'clean-saas'. Omit only if passing customTokens. | |
| overrides | No | ||
| customTokens | No | Full custom token set (same shape as a preset's tokens). Use for a bespoke system. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it writes tokens.json + design/*.md and returns a TOKEN CONTRACT. Without annotations, this provides good insight, but lacks details on destructiveness (overwrites?) or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, efficient. Could include the exclusivity constraint, but still concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the two usage methods and return value, but lacks clarity on exclusivity of presetId/customTokens (schema allows both) and the meaning of 'lock.' Useful but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the input schema: explains the OR logic between presetId and customTokens, provides examples for overrides and customTokens. Schema coverage is 67% and description compensates with usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lock the design system.' It specifies the two usage modes (presetId with overrides OR customTokens) and distinguishes from siblings by referencing pixl_list_presets for presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use presetId from pixl_list_presets with optional overrides, or customTokens for bespoke systems. Does not explicitly state when not to use, but the reference to pixl_list_presets implies it for listing presets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set/update the user-journey graph the flow canvas renders. Provide the edges (transitions between screen ids). Nodes default to one per planned screen and keep any positions the user has dragged. Writes flow.json and live-updates the Flow tab.
| Name | Required | Description | Default |
|---|---|---|---|
| edges | Yes | Directed transitions between screens. | |
| nodes | No | Optional explicit node set/positions; omit to use one node per screen. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: it writes to flow.json and live-updates the Flow tab. It also explains default node behavior and position preservation. Since no annotations are provided, the description carries the full burden and adequately addresses transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, with each sentence adding essential information: purpose, input requirements and defaults, and side effects. It is front-loaded and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two parameters, no output schema), the description covers all necessary aspects: what it does, what to provide, default behavior, and side effects (file write and UI update). No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3, but the description adds value by explaining that 'Nodes default to one per planned screen and keep any positions the user has dragged', which goes beyond the schema's descriptions of edges and nodes arrays.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb 'Set/update' and the resource 'user-journey graph the flow canvas renders', clearly defining the tool's action and target. It differentiates from sibling tools by detailing the focus on edges and node defaults, which is unique among the listed sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to set/update the flow graph) and mentions the input required (edges). However, it does not explicitly state when not to use it or list alternative tools for related tasks, such as pixl_plan_screens, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report current workspace state: whether initialized, the active design system, screen count, flow node count, and preview URL.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output fields and that the tool reports state (read operation). However, it does not mention potential prerequisites or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the verb and resource, lists all reported items. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all intended outputs given the tool's simplicity. It could be enhanced with format details or error scenarios, but it is largely complete for this status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the description does not need to add parameter information. The description adds value by listing the output fields, which compensates for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Report current workspace state' and lists specific reported fields (initialized, design system, counts, preview URL). This distinguishes it from siblings like pixl_init or pixl_set_design_system, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking state but does not explicitly state when to use it over alternatives or provide prerequisites. Usage is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a screen's HTML. It is linted against the token contract; on pass it is saved to screens/.html and live-renders in the gallery, on fail the violations are returned and NOTHING is saved — fix them and resubmit.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Screen id; matches a screen from pixl_plan_screens. | |
| html | Yes | Full self-contained HTML document for the screen, sized to the viewport and using the contract's headBlock + role classes. | |
| name | Yes | Human-readable screen name. | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description discloses that the input is linted, nothing is saved on failure, and on success the screen is saved and live-rendered. Missing details about overwrite behavior or authentication, but sufficiently transparent for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each packed with information: action, linting, conditional save, failure behavior. No filler, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions return on failure ('violations are returned') but omits success response details. Sibling list provides context. Missing those details slightly reduces completeness; still highly usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (75%), so the tool description adds little per-parameter detail beyond the linting context. The description reinforces that 'html' must conform to the token contract, but the schema already says that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (submit/write), resource (screen's HTML), and outcome (saved if passes lint, returned violations if fails). It distinguishes from sibling tools like pixl_lint_screen by showing this tool performs conditional save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the linting step and the condition for saving, giving clear context for use. It implies when to use (when ready to save after ensuring lint passes) but does not explicitly exclude using lint-only tool first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0pixl_initpixl_lint_screenpixl_list_presetspixl_plan_screenspixl_set_design_systempixl_set_flowpixl_statuspixl_write_screenEach tool has a unique, clearly defined purpose (init, lint, list presets, plan screens, set design system, set flow, status, write screen) with no overlap or ambiguity.
All tools follow a consistent 'pixl_verb_noun' pattern in snake_case, making the naming predictable and understandable.
8 tools is well within the optimal range for a specialized server covering initialization, design system, planning, linting, and writing screens.
The tool set covers the core workflow end-to-end, though there is no explicit tool to list or delete screens (pixl_status only reports count). This minor gap does not significantly hinder usability.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Live React design-system APIs, patterns, and code validation so AI agents build real UI, not slop.
Serves your design system and coding standards to coding agents, so they stop guessing.
Build, version, review, and export websites, web apps, and games from a conversation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ishk9/pixl'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
