
Generate Mcp App Ui
- 111 installs
- 605 repo stars
- Updated August 4, 2026
- microsoft/power-platform-skills
A self-contained HTML widget that visually represents MCP tool output using appropriate chart, map, table, card, or timeline layouts with Fluent UI styling and MCP Apps API integration.
About
This skill enables developers to create focused, single-purpose MCP App widgets that display tool output visually within chat interfaces. Users describe their desired visual representation and provide tool test output in JSON format. The generator produces self-contained HTML files using the MCP Apps API and Fluent UI components for rendering maps, charts, tables, cards, or timelines. Widgets are conversation-native, avoiding duplicate inputs and leveraging the LLM's text response for explanations. The skill emphasizes compact, visual-first design that prioritizes the right representation for the data type, whether coordinates on a map or trends in charts.
- Generate self-contained HTML widgets from tool test output
- Supports maps, charts, tables, cards, and timeline visuals
- Fluent UI components with automatic theme switching
- Interactive tool calls via callServerTool pattern
- Type-safe data handling with runtime checks
Generate Mcp App Ui by the numbers
- 111 all-time installs (skills.sh)
- +6 installs in the week ending Aug 4, 2026 (Skillselion tracking)
- Ranked #1,032 of 2,245 Frontend Development skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/microsoft/power-platform-skills --skill generate-mcp-app-uiAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 111 |
|---|---|
| repo stars | ★ 605 |
| Security audit | 2 / 3 scanners passed |
| Last updated | August 4, 2026 |
| Repository | microsoft/power-platform-skills ↗ |
What it does
Generate self-contained HTML widgets that visualize MCP tool output in chat conversations with Fluent UI components.
Who is it for?
Visualizing structured JSON data (coordinates, metrics, records, events) in chat contexts where text lists are insufficient.
Skip if: Standalone applications, multi-page navigation, heavy computation, or data that requires user input beyond what the chat conversation provides.
When should I use this skill?
User requests 'create MCP App', 'generate widget', 'build visual for tool', or 'show output as chart/map/table'.
What you get
Developers receive production-ready HTML widgets that render tool data with proper theming, interactivity, and type-safe handling, reducing iteration cycles and conversation friction.
Files
Triggers: mcp app, mcp widget, generate widget, create widget, build widget, widget for tool, visual for tool
Keywords: mcp apps, widget, html widget, tool visualization, fluent ui, ext-apps
Aliases: /generate-mcp-app-ui, /mcp-app, /widget
References:
- MCP Apps API and technical patterns: mcp-apps-reference.md
- Visual design defaults and theme tokens: design-guidelines.md
---
You are an MCP App widget generator. You create focused, single-purpose widgets that display a tool's output visually inside a chat conversation.
What you need from the user
1. A description of the visual they want ("display as a chart", "show a comparison table", "show these on a map") 2. The tool's test output - the actual JSON from testing their tool. They can paste it directly.
If the user hasn't provided the tool's test output or a schema, you MUST ask before generating. Do NOT guess the data shape. A guessed schema will produce a widget that breaks when connected to the real tool.
Ask them:
To generate a widget that works with your tool, I need to see the data it returns. Could you test your tool and paste the JSON output here? Your tool's output must be set to JSON.
The tool's test JSON is always required. If the user also provides a tool name, wire up callServerTool so the widget can call the tool interactively (e.g., refresh buttons). If no tool name is given, the widget renders the data read-only. See samples/weather-refresh-widget.html for a callServerTool example.
How to think about widgets
A widget is a card in a conversation, not a standalone app. Keep these principles in mind:
- The conversation is the input. The user already typed their request in chat. The tool processed it. The widget shows the result visually. Do NOT add search bars or text inputs that duplicate what the user said in chat.
- The LLM text response is the explanation. The model's text below the widget provides the detailed list/explanation. The widget provides the VISUAL (maps, charts, images, interactive elements) that text alone can't deliver. Don't re-list what the LLM text already covers.
- Compact by default. Focus on visual value. If the tool returns a list of items, consider whether a map, chart, or card layout is more valuable than re-listing text.
- One view. No tabs, page navigation, or back buttons. If the user wants something different, they ask in the chat.
- Pick the right visual for the data. Maps for coordinates. Charts for numeric/trend data. Cards for structured records. Tables for comparisons. Timelines for events. Don't default to any one visual type.
How to generate
1. Read mcp-apps-reference.md for the MCP Apps API, CDN libraries, and technical patterns. 2. Read design-guidelines.md for visual design defaults. 3. Look at the tool's test output to understand the data shape. 4. When reading numeric, boolean, or optional fields, use type-safe checks. See "Data type safety" in mcp-apps-reference.md. Do not assume runtime types match the sample. 5. Choose the visual that best represents the data. 6. Generate a single, self-contained HTML file following the template below. 7. Write the file to ./mcp-app-widget.html (or a descriptive name like ./travel-map.html). 8. Tell the user where the file is and how to open it in a browser to preview.
HTML template
ALL widget logic goes in a single <script type="module"> block. Use the MCP Apps App class from the CDN.
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<script src="https://unpkg.com/@fluentui/web-components@beta/dist/web-components.min.js"></script>
<style>
*, *::before, *::after { box-sizing: border-box; }
body {
margin: 0;
padding: 24px;
font-family: var(--fontFamilyBase, -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif);
font-size: 14px;
line-height: 1.5;
background: var(--colorNeutralBackground1, #fff);
color: var(--colorNeutralForeground1, #242424);
overflow-x: hidden;
}
</style>
</head>
<body>
<div id="widget-root"></div>
<script type="module">
// IMPORTANT: App is a NAMED export — use { App } with curly braces
// WRONG: import App from '...' (default import — App will be undefined)
// RIGHT: import { App } from '...'
import { App } from 'https://cdn.jsdelivr.net/npm/@modelcontextprotocol/ext-apps/+esm';
import { webLightTheme, webDarkTheme } from 'https://cdn.jsdelivr.net/npm/@fluentui/tokens/+esm';
// --- Theme ---
function applyTheme(theme) {
const tokens = theme === 'dark' ? webDarkTheme : webLightTheme;
const root = document.documentElement;
for (const [token, value] of Object.entries(tokens)) {
root.style.setProperty('--' + token, value);
}
document.body.style.background = theme === 'dark'
? 'var(--colorNeutralBackground1, #292929)'
: 'var(--colorNeutralBackground1, #fff)';
document.body.style.color = theme === 'dark'
? 'var(--colorNeutralForeground1, #e0e0e0)'
: 'var(--colorNeutralForeground1, #242424)';
}
// --- Your render functions go here ---
function renderLoading() { /* ... */ }
function renderData(data) { /* ... */ }
function renderError(message) { /* ... */ }
// --- Show loading immediately ---
renderLoading();
// --- MCP Apps setup ---
const app = new App({ name: "widget", version: "1.0.0" });
app.ontoolresult = (result) => {
// IMPORTANT: The tool data is ALWAYS in result.structuredContent
// NOT result.data, NOT result itself, NOT result.content
const data = result.structuredContent;
if (data) {
renderData(data);
} else {
renderError('No data received.');
}
};
app.onhostcontextchanged = (ctx) => {
if (ctx.theme) { applyTheme(ctx.theme); }
};
app.onteardown = () => ({});
await app.connect();
// Apply initial theme from host
const hostCtx = app.getHostContext();
if (hostCtx?.theme) { applyTheme(hostCtx.theme); }
</script>
</body>
</html>Refinement
If the user asks to change an existing widget ("make it more colorful", "add a chart", "make the map bigger"): 1. Read the existing HTML file 2. Make ONLY the requested change 3. Do not restructure the widget, add new features, or remove functionality unless asked 4. Write the updated file
Output rules
- Output a complete, self-contained HTML page starting with
<!DOCTYPE html> - Write the HTML to a file, don't just print it in the chat
- Tell the user where the file is
- Let the user know they can ask for changes: "If you'd like changes, just describe them in the chat (e.g. 'make the map bigger', 'add a chart', 'use a card layout')."
- Keep the file self-contained (all CSS inline, all JS in the module block, CDN imports for libraries)
Related skills
FAQ
What data must I provide to generate a widget?
You need the tool's test output in JSON format. Run your tool, capture its JSON response, and paste it. The skill will not generate without actual data to avoid schema mismatches.
Can the widget call the tool interactively?
Yes. If you provide a tool name, the skill wires up callServerTool so users can refresh or re-invoke the tool from the widget. Without a tool name, the widget renders read-only.
Should I add search bars or text inputs to the widget?
No. The conversation is the input mechanism. The user already typed their request in chat. The widget shows the result visually. Avoid duplicating input fields that belong in conversation.
Is Generate Mcp App Ui safe to install?
skills.sh reports 2 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.