generate-mcp-app-ui
This Claude Code skill generates self-contained HTML widgets that visually display MCP tool outputs within chat conversations. Use it when a user requests creation of an interactive widget, dashboard card, or visual representation for a tool, providing both a description of the desired visual format and the tool's JSON test output.
git clone --depth 1 https://github.com/microsoft/power-platform-skills /tmp/generate-mcp-app-ui && cp -r /tmp/generate-mcp-app-ui/plugins/mcp-apps/skills/generate-mcp-app-ui ~/.claude/skills/generate-mcp-app-uiSKILL.md
**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](../../references/mcp-apps-reference.md)
- Visual design defaults and theme tokens: [design-guidelines.md](../../references/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](../../references/mcp-apps-reference.md) for the MCP Apps API, CDN libraries, and technical patterns.
2. Read [design-guidelines.md](../../references/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.
```html
<!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 {Guide the user to add a data source, connection, or API connector to a Canvas App via Power Apps Studio, then verify and continue. USE WHEN the user asks to add a data source, add a connection, add an API, add a connector, connect to SharePoint / Dataverse / SQL / Excel / OneDrive / Teams / Office 365, or any similar request to make new data available to the app. DO NOT USE WHEN the user is asking to list or describe existing data sources — call list_data_sources or list_apis directly instead.
Creates or edits a Power Apps Canvas App through the Canvas Authoring MCP coauthoring session. Handles new app generation from requirements, simple inline edits, and complex multi-screen changes with parallel screen builders. Triggers on requests to create, build, generate, modify, update, change, or edit a Canvas App or .pa.yaml files.
Configure the Canvas Authoring MCP server for the current coauthoring session. USE WHEN "configure MCP", "set up MCP server", "MCP not working", "connect Canvas Apps MCP", "canvas-authoring not available", "MCP not configured", "set up canvas apps". DO NOT USE WHEN prerequisites are missing — direct the user to install .NET 10 SDK first.
[DEPRECATED — use canvas-app instead] Generate a complete Power Apps canvas app.
>
Adds Azure DevOps connector to a Power Apps code app. Use when querying work items, creating bugs, managing pipelines, or making ADO API calls.
Adds any Power Platform connector to a Power Apps code app. Generic fallback for connectors not covered by a specific skill.
Adds a data source or connector to a Power Apps code app. Asks what the user wants to accomplish and routes to the appropriate specialized skill.