What can you do with this server?

This server lets AI agents generate, render, manage, and analyze rich HTML artifacts from structured semantic specs, delivering them as full HTML or ui:// resource URIs. Core Tools * Render artifacts – Convert a declarative JSON spec into HTML. Supports v0.1 (safe static output) and v0.2 (richer, Chrome-first interactive layouts), with three delivery modes: static_html, mcp_app, or resource_only (ui:// URI). * Patch artifacts – Apply JSON Patch operations (add, replace, remove) to update a stored artifact incrementally. * Lint artifacts – Validate a spec or HTML against schema, accessibility, mobile, security, token cost, and size checks. * Export artifacts – Export a stored artifact as html, markdown, json, or prompt. * List artifacts – Retrieve paginated metadata (ID, title, pattern, revision, creation time) for all stored artifacts. * Search artifact patterns – Discover available patterns by query text or use case (e.g., planning, code_review, diagrams, decks). * Get artifact schema – Fetch the JSON schema, minimal example, and usage guidance for a specific pattern (e.g., slide_deck, triage_board, feature_explainer). Artifact Patterns (25 total) * v0.1 static: implementation_plan, code_review_explainer, design_variant_grid, research_report, custom_editor * v0.2 interactive: approach_comparison, slide_deck, feature_explainer, triage_board, module_map, clickable_flow, diagram_sheet, incident_report, prompt_tuner, and more. v0.2 Interactive Behaviors include tabs, filters, collapsibles, sliders, keyboard slide navigation, drag/reorder boards, dependency-aware toggles, live prompt previews, and sandboxed iframe prototypes. Safety: All model-provided text is HTML-escaped, no arbitrary model-generated JavaScript is executed, and sandboxed iframes block network and same-origin access.

Which integrations are available for this server?

Supports generating and serving CSS stylesheets for artifact rendering, including runtime CSS via resource URIs. Provides rendering and testing capabilities using Google Chrome/Chromium via Playwright, enabling sandboxed previews and deterministic local interactions. Enables artifact rendering with JavaScript runtime for interactive features such as tabs, sliders, and keyboard navigation, while preventing execution of arbitrary model-generated scripts.

How do I use web-gui-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@web-gui-mcp Render a feature explainer artifact for rate limiting." 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.

web-gui-mcp

by thehzuo

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

web-gui-mcp

web-gui-mcp is a Python MCP server that compiles compact GUI2 ArtifactSpec JSON into design-system-aware HTML artifacts.

The v0.3 pipeline is:

ArtifactSpec
-> studio model compiler
-> CompilerOutput { strategy, view_tree }
-> validated ViewTree + derived legacy RenderPlan metadata
-> DesignSystemPack resolver
-> deterministic HTML compiler
-> static HTML or ui:// resource

The remote model sends compact semantic specs by default. The studio compiler chooses composition, while the server owns validation, design-system tokens, escaping, CSP, and deterministic runtime code.

Setup

uv sync
uv run pytest
uv run ruff check .
uv run python scripts/render_example.py examples/v0_3/implementation_plan.json /tmp/web-gui-plan.html
uv run python scripts/render_artifact_library_pages.py

Without uv:

python -m venv .venv
. .venv/bin/activate
pip install -e ".[dev]"
pytest
ruff check .
python scripts/render_example.py examples/v0_3/implementation_plan.json /tmp/web-gui-plan.html
python scripts/render_artifact_library_pages.py

Related MCP server: CustomJS MCP Server

Run The MCP Server

uv run web-gui-mcp

The server exposes:

render_artifact
get_artifact
patch_artifact
list_artifacts
export_artifact
get_artifact_schema
compile_view_tree
lint_view_tree
list_design_systems
get_design_system_summary
get_local_model_status
recommend_studio_model
download_studio_model
cancel_model_download
list_themes
preview_theme
retheme_artifact
rerender_artifact

It serves:

ui://gui2/runtime/v0.3.css
ui://gui2/runtime/v0.3.js
ui://gui2/artifacts/{artifact_id}

Render An Artifact

render_artifact accepts compact semantic v0.3 specs:

{
  "spec": {
    "v": "0.3",
    "artifact": "implementation_plan",
    "title": "Queue Backpressure Plan",
    "audience": "engineer",
    "density": "compact",
    "sections": [
      {
        "kind": "summary",
        "items": [
          { "label": "Risk", "value": "Medium", "tone": "warning" }
        ]
      },
      {
        "kind": "checklist",
        "title": "Acceptance",
        "items": [
          { "text": "Default response returns a ui:// resource" }
        ]
      }
    ]
  },
  "quality": "studio",
  "delivery": "mcp_app_resource"
}

Default delivery returns compact metadata plus a ui://gui2/artifacts/{artifact_id} resource URI. Use delivery = "static_html" or return_html_to_model = true only when the caller explicitly needs full HTML in the tool response.

Studio Compiler

v0.3 is studio-only. The configured model provider receives the compact ArtifactSpec plus a design-system summary and produces CompilerOutput: compact strategy metadata plus the authoritative view_tree. The server validates and lints the ViewTree, derives deprecated RenderPlan metadata only for compatibility, then renders deterministic HTML. There is no deterministic fallback in normal rendering: if the model provider is unavailable or validation fails after one repair retry, the render fails closed.

Model providers:

stub: test provider that returns known valid CompilerOutput.
openai: default provider; uses gpt-5.5 with medium reasoning via the OpenAI API.
ollama: optional local provider; posts to /api/generate and validates CompilerOutput JSON.
auto: resolves to OpenAI unless WEB_GUI_RENDERER_PROVIDER overrides it.

OpenAI configuration:

export OPENAI_API_KEY=...

The server also reads .env.local in the repo root. Do not commit that file.

Optional local fallback model:

ollama pull qwen2.5-coder:14b

recommend_studio_model also lists larger quality targets for stronger hardware: qwen3.6:27b and qwen3-coder-next:q4_K_M.

Design Systems

The bundled gui2.default pack includes:

light/dark modes
compact/normal/comfortable/presentation density layers
neutral_pro, dense_engineering, executive_brief, and editorial_research themes
editorial_gallery for reference-library pages with numbered sections and demo cards
component contracts for the built-in ViewTree nodes
recipes for plans, reviews, design-variant grids, research, dashboards, and editors

Figma import and Code Connect ingestion are intentionally out of scope for this pass. The design-system schemas keep provenance fields so those importers can be added later.

Connect To Codex

[mcp_servers.web_gui_mcp]
command = "uv"
args = ["run", "web-gui-mcp"]
cwd = "/Users/hzuo/src/gui-mcp"
startup_timeout_sec = 20
tool_timeout_sec = 60
enabled = true

Without uv:

[mcp_servers.web_gui_mcp]
command = "python"
args = ["-m", "web_gui_mcp.server"]
cwd = "/Users/hzuo/src/gui-mcp"
startup_timeout_sec = 20
tool_timeout_sec = 60
enabled = true

Safety

All model-provided text is escaped before rendering.
ViewTree nodes are allowlisted and validated with Pydantic.
Props named like raw HTML, CSS, scripts, srcdoc, or event handlers are rejected.
Bind paths must resolve against the validated ArtifactSpec.
Semantic data nodes such as timeline, checklist, and summary_strip must bind to compatible non-empty artifact data.
JSON state embedded in <script type="application/json"> escapes <, >, &, U+2028, and U+2029.
The renderer never executes model-generated JavaScript.
The only runtime script is deterministic server-owned code for copy/export and tabs.

Available Tools

7 tools

export_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`artifact_id`	Yes
`format`	Yes
`content`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_artifact_schemaD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`pattern_id`	Yes
`schema`	Yes
`example_minimal`	Yes
`guidance`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lint_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`ok`	Yes
`issues`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_artifactsD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`artifacts`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

patch_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`artifact_id`	Yes
`delivery`	Yes
`title`	Yes
`html`	No
`resource_uri`	No
`byte_size`	Yes
`warnings`	Yes
`revision`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

render_artifactD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`artifact_id`	Yes
`delivery`	Yes
`title`	Yes
`html`	No
`resource_uri`	No
`byte_size`	Yes
`warnings`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_artifact_patternsD

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`patterns`	Yes

TDQS

D1/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Tool has no description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness1/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Tool has no description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Tool has no description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has no description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose1/5

Does the description clearly state what the tool does and how it differs from similar tools?

Tool has no description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Tool has no description.

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. Dates show when Glama detected each change.

7 tool updatesv0.1.0May 19, 2026
- First observedexport_artifact
- First observedget_artifact_schema
- First observedlint_artifact
- First observedlist_artifacts
- First observedpatch_artifact
- First observedrender_artifact
- First observedsearch_artifact_patterns

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.1/5.0

Disambiguation5/5

Each tool has a clearly distinct action (export, get schema, lint, list, patch, render, search) with no overlap, making it easy for an agent to select the correct one.

Naming Consistency5/5

All tools follow a consistent verb_artifact pattern (e.g., export_artifact, patch_artifact), with minor variations in the second part (artifact_schema, artifact_patterns) that are still clear.

Tool Count5/5

Seven tools is a well-scoped number for managing artifacts in a web GUI context, covering essential operations without being overwhelming.

Completeness3/5

The set includes list, get schema, patch, export, lint, render, and search, but lacks create and delete operations, which are notable gaps in a typical artifact lifecycle.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82
ShotAPI MCP Server A
io.github.smallhandsome
Screenshot and HTML render MCP server for AI agents
Browser Automation Image & Video Processing
21
Pdfrender A
dev.pdfrender
HTML-to-PDF MCP server — render pixel-faithful PDFs from HTML.
Workplace & Productivity
11
Keenable Web Search A
ai.keenable.api
Docs: https://docs.keenable.ai/mcp-server Keenable is a free, remote MCP server that gives agents access to the web index. Search the web with ranked results and date/site filters, then fetch any indexed page as clean markdown. Works out of the box with no account or API key.
Research & Data Search Web Scraping
23

Related MCP Servers

brewpage-mcp
Cloud Storage Developer Tools
kochetkov-ma
A
license
Not graded
quality
C
maintenance
MCP server for BrewPage, a free no-signup hosting service. Lets AI agents publish HTML, Markdown, JSON, files, or a full multi-file static site and get a public URL instantly via a REST API.
Updated 3 months ago (2026-06-14 08:16 UTC)
3
Apache 2.0
CustomJS MCP Serverofficial
Browser Automation Web Scraping Code Execution
customjs
A
license
Not graded
quality
D
maintenance
A remote MCP server that enables AI agents to host HTML pages, generate PDFs, capture screenshots, scrape sites, and run sandboxed code using a CustomJS API key.
Updated 3 months ago (2026-06-11 10:02 UTC)
MIT
Artifacts
Knowledge & Memory Content Management Systems File Systems
dbtlr
A
license
Not graded
quality
B
maintenance
MCP server that turns agent-generated Markdown, HTML, and text into persistent links, with tools to create, update, remove, list, and retrieve artifacts.
Updated 4 days ago (2026-09-04 11:48 UTC)
MIT
kairan
Developer Tools App Automation
ukwhatn
A
license
Not graded
quality
B
maintenance
A local MCP server that lets AI agents publish markdown/HTML to a browser viewer with session management, revision diffs, and live updates via a single tool call.
Updated 7 days ago (2026-09-01 12:47 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/thehzuo/gui-mcp'

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

web-gui-mcp

Setup

Run The MCP Server

Render An Artifact

Studio Compiler

Design Systems

Connect To Codex

Safety

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CustomJS MCP Serverofficial

Latest Blog Posts

MCP directory API