Generative UI MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | The host interface to bind the server to. | 127.0.0.1 |
| MCP_PORT | No | The port to listen on. | 8000 |
| MCP_SSE_PATH | No | The SSE endpoint path. | /sse |
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
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| generate_prefab_uiA | Execute Prefab Python code in a sandbox and render the result. The code runs in a Pyodide WASM sandbox with full Python support.
Import everything you use. Use the Always use PrefabApp as the outermost context manager — this enables streaming so the UI renders progressively as code is written: For interactive UIs, pass initial state as a dict and use
Available pipes: upper, lower, currency, length, json, round(n), default(val), truncate(n). Charts live in Values passed via Layout patterns:
Args: code: Python code that builds a Prefab component tree. data: Values injected as variables in the sandbox namespace. sandbox: A Sandbox instance. If not provided, a new one is created on each call. |
| search_prefab_componentsA | Search the Prefab component library. Use this tool to look up exact argument names, accepted values, and usage examples before writing component code. The skill covers patterns and layout; this tool has the API details. The query matches component names and descriptions.
Space-separated terms match independently, so
When a query matches a small number of components, full details
(docstrings, args, examples) are shown automatically. For broad
searches, a compact listing is returned instead. Use Args: query: Filter by component name or description. Space-separated terms are OR-matched. detail: Show full docstrings and args. Defaults to automatic (detailed for ≤5 matches, compact otherwise). limit: Max components to return in detail mode (default 8). No limit in compact mode. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Prefab Generative Renderer |
TDQS
Scored across 2 tools
generate_prefab_ui executes and renders UI code, while search_prefab_components is a reference lookup for available components and APIs. There is no overlap between rendering and searching, so an agent cannot confuse their roles.
Both tools follow the same lowercase verb_object pattern with the shared prefab_ prefix: generate_* and search_*. The minor difference between ui and components is not a meaningful inconsistency.
Two tools feels thin, but the server's scope is deliberately narrow: generate/render UI and search the component library. The count is acceptable but leaves little room for additional workflow support.
The tool pairing covers the full intended workflow: discover components with search_prefab_components, then generate and render them with generate_prefab_ui. No essential operation for a generative UI server is missing.