Using the power of language models many UIs have moved from complicated forms to friendly free text boxes. Free text boxes promise flexibility but often fail in practice. Users hesitate because they don’t know where to start. What’s valid? What’s possible? How much detail is enough. Without constraints, inputs vary wildly. From a UX standpoint, they hide affordances, create cognitive load, and shift responsibility from the system to the human. Guided inputs like dropdowns and radio buttons do the opposite: they make boundaries visible, surface options, and help users focus on the outcome instead of creating the perfect sentence.
We don’t believe that free text is the future of interfaces. Instead, we think the future lies in systems that can generate constrained, guided interfaces from natural language descriptions. This gives users the best of both worlds: the flexibility to express their needs in their own words, and the structure to ensure valid, efficient interactions.
For the teams and operators who just want to get work done, the Bridge now does the heavy lifting: you describe the screen you need in plain language, it understands the tools and data your company already trusts, according to their access rights, and it responds with a polished, guided interface ready to use. No fiddling with prompts, no waiting on a developer, just the right buttons, filters, and guardrails appearing where you need them.
The Enterprise MCP Bridge now generates complete web applications from natural language prompts. No build step, no frontend framework, no separate repository. The bridge takes in your prompt, reads your MCP tool schemas, generates an interactive UI, and serves it scoped to user or group identity.
Let’s have a look
Generating a User Interface for an time-off mcp server with a short prompt
What is this about and why do you need that over everything else that exists in the world
This is what happens when the systems you already rely on finally meet an interface that speaks their language. You can literally tell the bridge, “generate me a nice interface to our ERP to hand in my purchase request” and in a few seconds you have a guided workflow that respects the same rules your ERP team guards so carefully. The bridge reads the MCP schemas your ERP provides, inspects your current processes, surfaces the right controls, and gives you a safe, branded UI that plugs straight into production.
Instead of filing a ticket and waiting weeks for a bespoke dashboard, you describe the job in plain English. The bridge keeps every permission, audit requirement, and design token intact. Your operators get a purpose-built screen, your security team gets the audit trail, and your product teams get to move on. It’s the fastest path from “I wish I had a button for this” to an interface that exists, behaves, and persists like any other first-party app.
Tech Deepdive - How it works
When you POST a prompt to /_generated/{scope}, the bridge:
Extracts your OAuth identity and validates scope (user or group)
Queries the MCP server for available tools and their input/output schemas
Constructs a generation request with tool definitions and your design system prompt
Streams structured JSON over SSE as the LLM generates HTML and metadata
Writes the result to disk as a versioned artifact with full history
The generated HTML uses pfusch - a minimal progressive enhancement library that runs in the browser with zero build tools. State is mutable. DOM updates are direct. Event listeners are declarative. The model produces working HTML first, then enhances it with reactive components.
A single request:
curl -X POST “<http://localhost:8000/_generated/group=eng>” \
-H “Content-Type: application/json” \
-d ‘{
“id”: “absence-dashboard”,
“name”: “Absence Dashboard”,
“prompt”: “Show employee absence data with filters for date range and type”,
“tools”: [”list_absence_types”, “get_absences”]
}’
When complete, the dashboard is available at /_generated/group=eng/absence-dashboard/Absence Dashboard?as=page.
If the result is not satisfactory, you can POST what you want changed to the same URL again:
curl -X POST “<http://localhost:8000/_generated/group=eng/absence-dashboard>” \
-H “Content-Type: application/json” \
-d ‘{
“prompt”: “Add a bar chart showing absences by type”
}’
The bridge will review the past changes, apply the new prompt, and generate an updated UI.
And each update appends to the history array. As we add more features you will be able to diff prompts, compare outputs, and roll back to previous versions. The metadata tracks who changed what and when, giving you a full audit trail.
Scoping and access control
Generated UIs inherit authentication from the facade. User-scoped apps (user=alice) are writable only by that user. Group-scoped apps (group=eng) are writable by any group member. All fetch calls from generated UIs include the user’s OAuth token, so MCP tools enforce the same access control as programmatic API usage.
The bridge stores each UI as a JSON record:
metadata: scope, creator, timestamps, full generation historycurrent.html.page: Complete HTML documentcurrent.html.snippet: Embeddable fragment
You can retrieve the raw JSON (?as=card), render the full page (?as=page), or embed the snippet (?as=snippet).
Tool schema awareness
The LLM receives tool definitions with both input and output schemas. When generating fetch calls, it knows:
The exact endpoint:
{{MCP_BASE_PATH}}/tools/{tool_name}The POST body structure (input schema)
The response envelope (MCP protocol:
{ content, isError, structuredContent })The data structure inside
structuredContent(output schema)
This eliminates guesswork. The model doesn’t hallucinate field names or invent API contracts. It reads the schema and generates correct fetch logic. This also means that this works best with defined input/output schemas rather than freeform text.
Design system integration
LLMs are already great working with MCP tools - thanks to the Enterprise MCP Bridge they can now leverage that knowledge to build interfaces that interact with those tools as they would, as they are available in their most native web form (REST), making it easy to integrate it into any website.
Many people and companies have shown UIs created by AI, but few have tackled design system integration. More often, each generated UI is a one-off that looks different from the rest of the product, and from itself if regenerated later.
This is not what you need in an enterprise setting. The bridge solves this by integrating with your existing design system.
To help it understand your design system, you can define a system-defined prompt named design-system and the bridge injects it into every generation request. The model applies your typography, spacing, color tokens, and component patterns automatically. Update the prompt, regenerate the UI, and the new design is applied without touching code. You can directly embed the snippets into your existing applications, as long as you follow this rule: Because pfusch components use shadow DOM, you must mark shared styles with data-pfusch
<link rel=”stylesheet” href=”/design.css” data-pfusch>
<style data-pfusch>
.card { border: 1px solid var(--gray-200); }
</style>
This allows Pfusch to automatically link the relevant parts into the shadow dom, styling components as you would expect it.
The bridge’s generation prompt documents this requirement, and the model includes it, so for pages this is automatic.
Why this changes the calculus
Traditional frontend development for enterprise tools costs months and requires dedicated teams. This system collapses that timeline to minutes. Product teams describe requirements in prose. The bridge generates working interfaces that call real APIs, enforce real permissions, and apply real design systems.
If the tool schema changes, regenerate the UI. If the design system evolves, regenerate the UI. If a new feature is needed, send a new prompt. The cost of iteration drops from sprint cycles to seconds.
For compliance-heavy organizations: one LLM gateway, one authentication boundary, one audit trail. Generated UIs are artifacts you can version, review, and deploy through your existing infrastructure. We have open sourced the Enterprise MCP Bridge to make it easy to more companies to move in this direction. The Enterprise MCP Bridge, however is only a small step. Our platform is an integrated solution that allows you to Vibe Code, not just a single UI, but your entire enteprise.