io.github.alexalexalex222/frontend-design-loop-mcp
Click on "Deploy 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., "@io.github.alexalexalex222/frontend-design-loop-mcpImprove the landing page design to look more premium."
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.
Frontend Design Loop MCP
Coding agents can get a page functional. Frontend Design Loop makes it materially better with screenshot-grounded iteration and proof artifacts.
Use it when the base model got the page working but the result is still generic, flat, rough, or visibly under-designed. The main design workflow stays on one main provider and model lane by default, so multi-model routing is opt-in instead of the default story.
Quick Start
Install the current public build from PyPI:
pipx install frontend-design-loop-mcpSet up every detected supported client:
frontend-design-loop-setup --install-all-detected-clientsReal MCP call example:
frontend_design_loop_design(
repo_path="/absolute/path/to/site",
goal="make the homepage look materially more premium without changing the information architecture",
provider="gemini_cli",
model="gemini-3.1-pro-preview",
preview_command="python3 -m http.server {port}",
preview_url="http://127.0.0.1:{port}/index.html"
)Related MCP server: vibe-annotations
Agent-Owned Toolkit Variant
This repo now also ships an additive MCP entrypoint for agent-owned frontend loops:
console script:
frontend-design-toolkit-mcpmodule fallback:
PYTHONPATH=src .venv/bin/python -m design_toolkit.server
That variant is intentionally narrow:
get_playbookbuild_contextrun_gatespreview_startcapture_screenshotspreview_stop
It does not hide vision scoring, creativity judging, or patch generation behind MCP. The host agent owns planning, edits, screenshot review, scoring, iteration, and winner selection directly.
See test-prompt-codex.md for the end-to-end Codex exercise prompt.
What The MCP Does
frontend_design_loop_design is the main workflow:
the host agent points the MCP at a real repo plus a concrete design goal
the MCP boots a local preview, captures screenshots, and iterates against the rendered result
the same main provider and model lane is used by default across planning, generation, and vision unless you explicitly override it
the MCP returns the winning patch plus screenshots and run artifacts
frontend_design_loop_eval is the proof workflow:
use it when the host agent already has the patch
the MCP applies the patch in an isolated worktree, runs deterministic checks, captures screenshots, and returns proof artifacts
This is the wedge:
coding agents can already get pages working
this MCP helps them make pages materially better
screenshot-grounded iteration plus proof artifacts is the differentiator
Official MCP Registry metadata is tracked in server.json.
Proof Gallery
The public proof set uses owned/generated GA SMB previews plus the ACA full-page before/after.
Selected Hero / Top Crops
ACA Full-Page Before / After
Before: early ACA full homepage.

After: rebuilt ACA homepage with a stronger hero, cleaner sequencing, and a materially better full-page result.

See the proof notes in the case studies index.
How It Works In Practice
Point the MCP at a real repo and give it a concrete design goal.
It creates an isolated worktree, boots a preview, and captures rendered screenshots.
It iterates against the actual rendered page instead of only raw code.
It returns the winning patch, screenshot proof, and run artifacts so the host agent can judge the result.
Workflow Summary
frontend_design_loop_design
Use it when:
the page is functional but weak
the section structure is there but the design is not
you want the MCP to improve the page instead of only judging it
Key defaults:
one main
provider+modellane by defaultplanning_mode="single"vision_mode="on"section_creativity_mode="on"split planner or vision lanes only happen when explicitly requested
frontend_design_loop_eval
Use it when:
the host agent already has the patch
you want deterministic checks, screenshots, and artifact capture
you want the host agent to judge the result from returned screenshots
Returned proof fields include:
deterministic_passedvision_pendingvision_scoredfinal_passrun_dircandidate_dirscreenshot_filespatch
frontend_design_loop_solve
frontend_design_loop_solve still exists for advanced unattended workflows, but it is not the main public story.
Install And Setup
Public install now
pipx install frontend-design-loop-mcp
frontend-design-loop-setup --install-all-detected-clientsGitHub install remains the fallback:
pipx install git+https://github.com/alexalexalex222/frontend-design-loop-mcp.git
frontend-design-loop-setup --install-all-detected-clientsLocal clone path
git clone https://github.com/alexalexalex222/frontend-design-loop-mcp.git
cd frontend-design-loop-mcp
./scripts/setup.shThe local setup path:
creates
.venvinstalls the package
installs Playwright Chromium
installs detected client entries when supported clients are present
runs the built-in doctor
runs the stdio smoke test
If you want the repo-local environment without auto-installing client entries:
FDL_SKIP_CLIENT_INSTALL=1 ./scripts/setup.shSetup helpers
Bulk installer:
frontend-design-loop-setup --install-all-detected-clientsTargeted installers:
frontend-design-loop-setup --install-claude --scope user
frontend-design-loop-setup --install-codex
frontend-design-loop-setup --install-gemini
frontend-design-loop-setup --install-droid
frontend-design-loop-setup --install-opencodeConfig printers:
frontend-design-loop-setup --print-claude-config
frontend-design-loop-setup --print-codex-config
frontend-design-loop-setup --print-gemini-config
frontend-design-loop-setup --print-droid-config
frontend-design-loop-setup --print-opencode-configSafety Defaults
custom commands are parsed as shell-free argv by default
shell syntax, substitutions, and inline interpreter execution like
bash -c,python -c, andnode -erequireunsafe_shell_commands=truepreview_urlmust match the launched local preview origin and port by defaultexternal preview fetches require
unsafe_external_preview=truepreview readiness checks reject cross-origin redirects, and browser screenshots block cross-origin subresources by default
auto-context skips common secret-bearing paths such as
.env*,.git/,.aws/,.ssh/,.config/gcloud/,.docker/,.kube/, token-named files, and service-account-style JSONnative CLI providers inherit a minimal allowlisted environment instead of the full host shell environment
shared worktree reuse directories are off by default
Client-side vision is the default proof path for frontend_design_loop_eval, so the host agent can judge the screenshots without provider credentials.
Proxy-only MiniMax vision lanes are explicitly treated as structural-only review:
vision_review_mode="proxy_structural"they do not count as full automated visual scoring
Verification
Offline preflight:
PYTHONPATH=src .venv/bin/python scripts/preflight_check.pystdio smoke:
PYTHONPATH=src .venv/bin/python scripts/smoke_mcp_stdio.pyBuilt-in doctor:
frontend-design-loop-setup --doctor
frontend-design-loop-setup --doctor --smokeDocs
Distribution State
Current public install path:
pipx install frontend-design-loop-mcpAvailable Tools
1 toolfrontend_design_loop_evalD
MCP tool wrapper for _frontend_design_loop_eval_impl.
Returns:
JSON summary (TextContent)
Optional vision instructions (TextContent) when vision_provider=client
Optional screenshots as ImageContent (base64) so Claude can use built-in vision
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| patches | Yes | ||
| repo_path | Yes | ||
| viewports | No | ||
| preview_url | No | ||
| vision_mode | No | auto | |
| lint_command | No | ||
| test_command | No | ||
| vision_model | No | gemini-2.0-flash | |
| keep_worktree | No | ||
| include_images | No | ||
| gate_timeout_ms | No | ||
| preview_command | No | ||
| vision_provider | No | client | |
| worktree_reuse_dirs | No | ||
| unsafe_shell_commands | No | ||
| preview_wait_timeout_s | No | ||
| vision_score_threshold | No | ||
| unsafe_external_preview | No | ||
| include_vision_instructions | No | ||
| vision_broken_min_confidence | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions return types; no disclosure of side effects, permissions, or limitations. Inadequate for safe invocation.
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?
Description is short but contains redundant info about return types (output schema exists). Lacks substance to earn its place.
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 21 parameters, no annotations, and no schema descriptions, the description is critically incomplete. It doesn't explain tool behavior or parameter meanings.
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 has 21 parameters with 0% description coverage in schema. Description adds zero parameter information, failing to compensate for the low coverage.
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 only states it's a wrapper for an implementation and lists return types, but does not specify what the tool does (e.g., evaluate frontend design). The purpose is vague and lacks a specific verb+resource.
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?
No guidance on when to use this tool or alternatives. The description provides no context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v1.0.0- First observed
frontend_design_loop_eval
TDQS
Scored across 1 tool
Only one tool exists, so there is no possibility of confusion with other tools. The tool's purpose is singular and unambiguous.
With a single tool, naming consistency is trivially perfect. The name uses a descriptive underscore-separated pattern.
A single tool for a 'frontend design loop' is far too few. The server promises a loop of design activities but only provides evaluation, missing creation, modification, or iteration tools.
The tool surface is severely incomplete. A design loop typically involves multiple steps (create, review, modify, test), but only an evaluation tool is provided, leaving critical gaps.
Maintenance
Related MCP Connectors
Design intelligence for coding agents: audits, design systems, and a taste profile agents consult.
UI design from prompts, screenshots, and URLs for AI coding agents and theme tokens.
Anti-slop design taste for AI coding agents: art directions, section code, 0-100 page critic.
Verification videos for AI coding agents: record the run, upload over MCP, share a viewer link.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceMCP server that enables AI coding agents to read and write to a local-first HTML/CSS design canvas, bridging visual design and code generation.1MIT
- FlicenseNot gradedqualityAmaintenanceMCP server that exposes web page annotations to AI coding agents, enabling automated implementation of visual feedback and design tweaks.4 npm163-
- FlicenseNot gradedqualityDmaintenanceA self-updating MCP system that analyzes design and code inputs with an LLM, refines them through conversation, and crystallizes approved patterns into a local skill library for MCP agents.-
- FlicenseAqualityDmaintenanceAn MCP server implementing a 7-stage agentic frontend workflow—from design audit to PR review—including AI-driven component generation, browser validation, E2E testing, and CI self-healing.44 npm-