Generate Mcp App Ui

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

Audit 0.4.1 · source sha 8075ef5705c5 · 18 Oct 2026Report an issue or request a re-scan

• Publishermicrosoft GitHub organizationOwner of the repository this skill is read from
• Source foldermicrosoft/power-platform-skills/plugins/mcp-apps/skills/generate-mcp-app-uiThe exact folder we audited
• LicenceMITAs the repository states it
• Commit pinned for this verdict8075ef5705c5A new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Generate a single-file MCP App widget for an MCP tool, with either bundled runtime code or user-approved public CDN imports. Describe the visual and provide a plain structured payload or a full tool result with content,…

---
name: generate-mcp-app-ui
version: 1.1.0
description: Generate a single-file MCP App widget for an MCP tool, with either bundled runtime code or user-approved public CDN imports. Describe the visual and provide a plain structured payload or a full tool result with content, structuredContent, and meta.
author: Microsoft Corporation
argument-hint: <description of what the widget should display>
user-invocable: true
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion
---

**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)
- Self-contained source template: [self-contained-widget.template.html](../../samples/self-contained-widget.template.html)

---

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. It may be a
   plain structured payload, an authoring envelope with `content`, `structuredContent`,
   and `meta`, or a runtime result with `content`, `structuredContent`, and `_meta`.
3. **Whether public CDN URLs are allowed.** If the user has not already stated the
   policy, ask:

   > Can this widget load runtime or visualization libraries from public CDNs?

   Present these choices in this order:

   1. **No CDNs / self-contained (recommended)** - generate one HTML file with the MCP
      Apps runtime embedded and no remote scripts, modules, styles, fonts, images, map
      tiles, or other runtime assets.
   2. **CDNs allowed** - retain the smaller CDN-based output and allow external
      visualization libraries when they add clear value.

   Do not silently choose CDN mode. If the user does not specify a preference, use the
   self-contained mode.

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. Normalize it before designing:

- A plain object with none of the reserved result keys represents `structuredContent`.
- An object containing `content`, `structuredContent`, or `meta` is an authoring result
  envelope. Rename `meta` to runtime `_meta`.
- An object containing `_meta` is already in runtime MCP result form.

`content` and `structuredContent` are model-visible. `_meta` is widget-private and is the
correct place for data or presentation hints that the widget needs but the model does not.
The widget may use any combination of these channels. Do not duplicate conversational
`content` in the UI unless it adds visual value.

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, delivery modes, libraries, and technical patterns.
2. Read [design-guidelines.md](../../references/design-guidelines.md) for visual design defaults.
3. Normalize the test output into the runtime `{ content, structuredContent, _meta }`
   shape and inspect every channel relevant to the requested visual.
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 one HTML file using the template for the selected delivery mode.
7. Write the file to `./mcp-app-widget.html` (or a descriptive name like `./travel-map.html`).
8. In self-contained mode, run the deterministic inliner before reporting completion:

   ```powershell
   node "${PLUGIN_ROOT}/scripts/inline-self-contained-runtime.js" --input "./mcp-app-widget.html"
   ```

   The script replaces the runtime marker in place and fails if the draft still contains
   external runtime/resource URLs.
9. Tell the user where the 

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/microsoft/power-platform-skills
git -C power-platform-skills checkout 8075ef5705c5

Works in

1. 2026-10-18
   ✓SAFE B 89 / 100

   first audit · source 8075ef5705c5

Questions about Generate Mcp App Ui

• github.com/microsoft/power-platform-skills/tree/main/plugins/mcp — the audited source at commit 8075ef5705c5 and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology