[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B3DNJBFY5GHVWXMQ8XG4H":3,"skill-same:01M69B3DNJBFY5GHVWXMQ8XG4H":111},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":56,"linkOnly":57,"markdownContent":58,"markdownBody":59,"frontMatter":60,"refName":61,"commitSha":62,"skillDirectory":63,"forksCount":64,"repositoryHtmlUrl":65,"repositoryHomepageUrl":66,"ownerHtmlUrl":67,"ownerBlogUrl":68,"ownerDescription":69,"updatedAt":70,"install":71,"resources":84},"01M69B3DNJBFY5GHVWXMQ8XG4H","ui-widget-developer",null,"Build MCP servers for Copilot Chat using the OpenAI Apps SDK or MCP Apps SDK widget rendering support (any language). Use this skill when:\n- Creating MCP servers that integrate with M365 Copilot declarative agents\n- Building rich interactive widgets (React + Fluent UI) that render in Copilot Chat\n- Implementing tools that return structuredContent for widget rendering\n- Adapting an existing MCP server to support Copilot widget rendering\n- Setting up devtunnels for localhost MCP server exposure\n- Configuring mcpPlugin.json manifests with RemoteMCPServer runtime\nDo NOT use this skill for general agent development (scaffolding, manifests, deployment) — use declarative-agent-developer instead. This skill is ONLY for MCP server + widget development.\nTriggers: \"MCP server for Copilot\", \"OpenAI Apps SDK\", \"Copilot widget\", \"structuredContent\", \"MCP plugin\", \"devtunnels MCP\", \"OAI app\", \"widget rendering\", \"UI widget\"","microsoft\u002Fskills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69AJYYW4E1RMSYCQDJ4FJSH",3202,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55],"widget","ui widget developer","ui","developer","declarative agents","when","implementing","manifests","render","apps","app","scaffolding","up","only","agent development","MCP","plugin","copilot chat","copilot","react","fluent","support","mcp server","sdk","2026-11-10 10:12:30",false,"---\nname: ui-widget-developer\ndescription: |\n  Build MCP servers for Copilot Chat using the OpenAI Apps SDK or MCP Apps SDK widget rendering support (any language). Use this skill when:\n  - Creating MCP servers that integrate with M365 Copilot declarative agents\n  - Building rich interactive widgets (React + Fluent UI) that render in Copilot Chat\n  - Implementing tools that return structuredContent for widget rendering\n  - Adapting an existing MCP server to support Copilot widget rendering\n  - Setting up devtunnels for localhost MCP server exposure\n  - Configuring mcpPlugin.json manifests with RemoteMCPServer runtime\n  Do NOT use this skill for general agent development (scaffolding, manifests, deployment) — use declarative-agent-developer instead. This skill is ONLY for MCP server + widget development.\n  Triggers: \"MCP server for Copilot\", \"OpenAI Apps SDK\", \"Copilot widget\", \"structuredContent\", \"MCP plugin\", \"devtunnels MCP\", \"OAI app\", \"widget rendering\", \"UI widget\"\n---\n\n# Copilot MCP Server Development\n\n## Telemetry Tagging\n\nBefore running any `atk` CLI commands, set the session environment variable so all CLI invocations are tagged as skill-initiated:\n```bash\nexport ATK_CLI_SKILL=true\n```\nRun this once at the start of the session. All subsequent `atk` commands in the same terminal will inherit it.\n\n## ? PATH SELECTION\n\n**Before proceeding, ask the user which path they want to take using AskUserQuestion.** Both are supported for M365 Copilot widget rendering. Present the tradeoffs and let them choose:\n\n| | **OAI Apps** (this skill) | **MCP Apps Extension** (`modelcontextprotocol\u002Fext-apps`) |\n|---|---|---|\n| **Standard** | OpenAI-specific | Official MCP standard |\n| **Works in** | ChatGPT + M365 Copilot | M365 Copilot, ChatGPT, VSCode, and more |\n| **Maturity** | Battle-tested, production-ready | New official standard, growing ecosystem |\n| **Design** | OpenAI Apps SDK | MCP Apps protocol (cross-platform) |\n| **When to choose** | Existing OAI app investment | Prefer the open standard, want broadest client support |\n\n**Ask:** _\"Would you like to build an OAI app (OpenAI Apps SDK — battle-tested, works in ChatGPT and M365 Copilot) or an MCP app (new official standard — works in M365 Copilot, ChatGPT, VSCode, and more)?\"_\n\n- **OAI apps** → Continue below. This skill covers everything you need.\n- **MCP apps** → Install the `modelcontextprotocol\u002Fext-apps` plugin (see below), then use the appropriate skill from that plugin.\n\n### MCP Apps: Install ext-apps Plugin\n\nIf the user chooses MCP Apps, do this automatically (do not stop at explanation-only):\n\n1. Run `\u002Fplugin marketplace add modelcontextprotocol\u002Fext-apps`\n2. Run `\u002Fplugin install mcp-apps@mcp-apps`\n3. Confirm the plugin is available, then invoke the correct ext-apps skill based on user intent\n\nIf plugin commands are unavailable in the current environment, provide the exact commands below and ask the user to run them once, then continue by invoking the selected ext-apps skill.\n\nReference commands:\n\n```\nTo build an MCP App, install the ext-apps plugin from the marketplace:\n\n1. \u002Fplugin marketplace add modelcontextprotocol\u002Fext-apps\n2. \u002Fplugin install mcp-apps@mcp-apps\n\nThen use one of these skills from that plugin:\n- create-mcp-app      — Scaffold a new MCP App with interactive UI from scratch\n- add-app-to-server   — Add interactive UI to an existing MCP server's tools\n- migrate-oai-app     — Convert an existing OAI app to use MCP Apps\n- convert-web-app     — Turn a web app into a hybrid web + MCP App\n\nAfter installing, invoke the relevant skill to continue.\n```\n\n> **Note:** The ext-apps plugin lives in the external `modelcontextprotocol\u002Fext-apps` marketplace — it is not part of this plugin collection.\n\n**Handoff mapping after install:**\n- New MCP app from scratch → `create-mcp-app`\n- Add app UI to existing MCP server → `add-app-to-server`\n- Migrate existing OAI app → `migrate-oai-app`\n- Convert an existing web app → `convert-web-app`\n\n---\n\n## ? PROJECT DETECTION ?\n\nThis skill triggers when building MCP servers with OAI app or widget rendering for Microsoft 365 Copilot Chat. The MCP server can be written in any language that supports the MCP protocol (TypeScript, Python, C#, etc.). The agent project and MCP server may live in the same repo, separate folders, or entirely different projects.\n\n## Scenario Routing\n\n| Starting Point | What You Need | Path |\n|---------------|---------------|------|\n| **Prefer MCP Apps standard** | Cross-platform widget support (M365 Copilot, ChatGPT, VSCode, and more) | Install `modelcontextprotocol\u002Fext-apps`, then use `create-mcp-app` or `add-app-to-server` — see [Path Selection](#-path-selection) above |\n| **From scratch** (no agent, no MCP server) | Full OAI app setup | Delegate agent scaffolding to `declarative-agent-developer` first, then return here for MCP server + widgets |\n| **Existing M365 agent, new MCP server** | MCP server + widgets + mcpPlugin.json | Start at [Implementation](#implementation) |\n| **Existing MCP server, add Copilot widgets** | Widget support added to existing server | Start at [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md#adaptation-checklist-existing-mcp-server) |\n| **Language choice** (non-TypeScript) | Protocol requirements | See [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md) for what to implement, [MCP Server Pattern (TypeScript)](references\u002Fmcp-server-pattern.md) as a reference |\n\n---\n\n## ? CRITICAL EXECUTION RULES ?\n\n\n**FLUENT UI ENFORCEMENT (REQUIRED):** Widget implementations MUST use React + Fluent UI components. Before writing any widget code, the agent MUST read and follow:\n- `references\u002Fwidget-patterns.md`\n- `references\u002Fbest-practices.md`\n**FLUENT UI PACKAGE REQUIREMENT (REQUIRED):** The widget project MUST include Fluent UI dependencies before implementation. At minimum, install and keep these in the widget package dependencies:\n- `@fluentui\u002Freact-components`\n- `react`\n- `react-dom`\n\nIf any of these packages are missing, install them automatically before continuing with widget code generation.\n\nIf the generated widget does not include React entry files (for example `widgets\u002Fsrc\u002F\u003Cwidget-name>\u002Fmain.tsx` and a React component file) and Fluent imports from `@fluentui\u002Freact-components`, the task is incomplete and MUST be corrected before returning results.\n\n**NO RAW HTML-ONLY WIDGETS (DEFAULT):** Do not implement app content directly with static HTML templates and inline JS as the final widget solution. A minimal shell HTML file is allowed only as a loader for built React assets. Raw\u002Fself-contained HTML-only widgets are allowed only when the user explicitly requests a non-React prototype.\n\n**BACKGROUND PROCESSES:** MCP server and devtunnel MUST be spawned as independent OS processes — NOT run inside the agent's shell session. `isBackground: true`, `mode: \"async\"`, and `Start-Job` all run inside the agent's shell session and will be killed between messages. The only reliable approach is to spawn a detached OS process.\n\n**Windows — use `Start-Process -WindowStyle Hidden`:**\n```powershell\n# Start devtunnel\n$t = Start-Process -FilePath \"devtunnel\" `\n    -ArgumentList \"host\",\"\u003Ctunnel-name>\",\"-a\" `\n    -WindowStyle Hidden -PassThru `\n    -RedirectStandardOutput \"tunnel.log\" -RedirectStandardError \"tunnel-err.log\"\n\n# Start MCP server — use cmd.exe \u002Fc to set the working directory and inherit PATH\n$s = Start-Process -FilePath \"cmd.exe\" `\n    -ArgumentList \"\u002Fc\",\"cd \u002Fd \u003Cabs-path-to-mcp-server> && \u003Cstart-command>\" `\n    -WindowStyle Hidden -PassThru `\n    -RedirectStandardOutput \"server.log\" -RedirectStandardError \"server-err.log\"\n\n# Save PIDs so they can be stopped later\n\"$($t.Id),$($s.Id)\" | Out-File pids.txt\nWrite-Host \"Started tunnel PID $($t.Id), server PID $($s.Id)\"\n```\nTo stop: `Stop-Process -Id (Get-Content pids.txt).Split(',')` or `Stop-Process -Id \u003Cpid>`.\n\n**Linux\u002FMac — use `nohup` with `&`:**\n```bash\nnohup devtunnel host \u003Ctunnel-name> > tunnel.log 2>tunnel-err.log &\necho \"tunnel:$!\" >> pids.txt\nnohup \u003Cstart-command> > server.log 2>server-err.log &\necho \"server:$!\" >> pids.txt\n```\nTo stop: `kill $(grep -oP '\\d+' pids.txt)`.\n\nAfter starting, tail the logs to confirm both processes are up before proceeding:\n```powershell\n# Windows\nStart-Sleep 3; Get-Content tunnel.log, server.log\n```\n```bash\n# Linux\u002FMac\nsleep 3 && tail tunnel.log server.log\n```\n\n**FULL AUTOMATION:** Never tell the user to run commands manually. Install tools, authenticate, start services — do everything automatically. Only ask the user for interactive input that truly requires them (like device code confirmation during `devtunnel user login -g -d`). If a tool isn't installed, install it. If a service needs starting, start it. The user expects full automation.\n\n**PATH SELECTION (REQUIRED — STOP BEFORE ANY CODE):** You MUST use `AskUserQuestion` to ask the user whether they want OAI Apps or MCP Apps Extension before writing any code, running any commands, or making any architectural decisions.\n\n**There is no exception to this rule.** The most common failure mode is reasoning \"the user's request makes it obvious, so asking is redundant.\" This reasoning is always wrong — invoke `AskUserQuestion` regardless. A user saying \"build an MCP server with widgets\" is NOT an answer to this question. A user invoking this skill by name is NOT an answer. Only an explicit answer to the question counts. See [PATH SELECTION](#-path-selection) above for the exact question to ask.\n\n**AGENT PROVISIONING:** Re-provisioning is only required when the **agent manifest** changes (e.g., mcpPlugin.json tool definitions, MCP server URL, declarativeAgent.json, instruction.txt). MCP server code changes (tool implementations, React widget code, server logic) do **NOT** require re-provisioning the agent — running or deploying the server picks up changes automatically.\n\nWhen provisioning is needed:\n1. **Bump the version** in `manifest.json` (increment the patch version, e.g., `1.0.0` → `1.0.1`)\n2. **Deploy the agent:**\n   ```bash\n   npx -y --package @microsoft\u002Fm365agentstoolkit-cli atk provision --env local\n   ```\n\n**WIDGET TESTING LINKS:** Every time you return to the user with a result while the MCP server is running, you MUST include links to ALL widgets so they can test them locally. Format:\n```\n? Test widgets locally:\n- http:\u002F\u002Flocalhost:3001\u002Fwidgets\u002Fwidget-name.html\n- http:\u002F\u002Flocalhost:3001\u002Fwidgets\u002Fanother-widget.html\n```\nList every `.html` file in the `mcp-server\u002Fwidgets\u002F` directory (or equivalent widget folder). This helps users verify widget rendering before testing in Copilot.\n\n**AUTO-DEPLOY ON COMPLETION (REQUIRED — DO NOT SKIP):** When coding is complete, proceed automatically without waiting for the user:\n1. Start MCP server + devtunnel in the background (per BACKGROUND PROCESSES above)\n2. Run E2E verification with MCP Inspector (per MCP TOOL CONFIGURATION RULE below) — fix any failures before continuing\n3. Provision the agent if needed (per AGENT PROVISIONING above)\n4. Print a project summary in this format:\n```\n## ✅ \u003CProject Name> — Ready\n\n### Widgets\n- [widget-name.html](http:\u002F\u002Flocalhost:\u003CPORT>\u002Fwidgets\u002Fwidget-name.html)\n- [widget-name2.html](http:\u002F\u002Flocalhost:\u003CPORT>\u002Fwidgets\u002Fwidget-name2.html)\n\n### Endpoints\n- MCP server: http:\u002F\u002Flocalhost:\u003CPORT>\u002Fmcp\n- MCP via tunnel: https:\u002F\u002F\u003Ctunnel-url>\u002Fmcp\n\n### Test in Copilot\nLocal:      https:\u002F\u002Fm365.cloud.microsoft\u002Fchat\u002F?titleId={M365_TITLE_ID from env\u002F.env.local}\nOther envs: {SHARE_LINK from env\u002F.env.{environment}}\n```\n\n**AGENT PROJECT DELEGATION:** This skill builds MCP servers and widgets, NOT declarative agent projects. If the user's request involves creating or configuring the declarative agent itself (scaffolding, `m365agents.yml`, `m365agents.local.yml`, `declarativeAgent.json`, manifest lifecycle), delegate to the `declarative-agent-developer` skill.\n\n**MCP RESOURCE REGISTRATION:** Every widget MUST have a matching MCP resource. Without resources, Copilot cannot fetch widget shells through the MCP protocol and widgets will not render.\n\nFor each new widget, complete this checklist:\n1. ☐ Create a widget shell HTML file in `widgets\u002F` and a React widget entry under `widgets\u002Fsrc\u002F\u003Cwidget-name>\u002F` (see widget-patterns.md)\n2. ☐ Define a `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI constant\n3. ☐ Add a `Resource` entry to the `resources` array with:\n   - `uri`: the `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI\n   - `mimeType`: `\"text\u002Fhtml+skybridge\"`\n   - `_meta`: CSP config with `openai\u002FwidgetDomain` and `openai\u002FwidgetCSP` (from environment)\n4. ☐ Add a handler for `resources\u002Fread` that returns the widget shell HTML for this URI\n5. ☐ Add the tool with `_meta.openai\u002FoutputTemplate` pointing to the same `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI\n6. ☐ Verify the server capabilities include `resources: {}` in the initialize response\n\n**Widget shell + asset considerations:**\n- **Preferred (React + Fluent UI)**: Resource HTML should be a minimal shell that links to built JS\u002FCSS assets served from the MCP server's `\u002Fassets\u002F` route.\n- **Exception only**: Self-contained HTML via `resources\u002Fread` is for explicit user-requested prototypes only. Default and production path is React + Fluent UI.\n\nExample shell for React build output:\n  ```html\n  \u003C!doctype html>\u003Chtml>\u003Chead>\n    \u003Cscript type=\"module\" src=\"${serverUrl}\u002Fassets\u002Fmy-widget.js\">\u003C\u002Fscript>\n    \u003Clink rel=\"stylesheet\" href=\"${serverUrl}\u002Fassets\u002Fmy-widget.css\">\n  \u003C\u002Fhead>\u003Cbody>\n    \u003Cdiv id=\"widget-root\">\u003C\u002Fdiv>\n  \u003C\u002Fbody>\u003C\u002Fhtml>\n  ```\n  Use the `WIDGET_BASE_URL` or `MCP_SERVER_URL` environment variable for the asset URL base (see mcp-server-pattern.md \"Configurable Widget Base URL\" section).\n\nSee [mcp-server-pattern.md](references\u002Fmcp-server-pattern.md) for the complete resource and asset serving patterns.\n\n---\n\n## ⚠️ MCP TOOL CONFIGURATION RULE ⚠️\n\n**NEVER manually write tool definitions in `mcpPlugin.json`.** Always use MCP Inspector to get the complete tool definitions from the running MCP server.\n\n**TOOL NAMING CONVENTION:** Tool names MUST match the pattern `^[A-Za-z0-9_]+$` (letters, numbers, and underscores only). **NEVER use hyphens (-) in tool names.** Use underscores instead (e.g., `render_profile` not `render-profile`).\n\n**MANDATORY WORKFLOW:**\n1. **Start the MCP server** (in background)\n2. **Use MCP Inspector** to get the latest tool definitions:\n   ```bash\n   npx @modelcontextprotocol\u002Finspector@0.20.0 --cli https:\u002F\u002Fmy-mcp-server.example.com --transport http --method tools\u002Flist\n   ```\n3. **Copy the COMPLETE tool definition** from the inspector (including `name`, `description`, `inputSchema`, `_meta`, `annotations`, `title`)\n4. **Paste into `mcpPlugin.json`** under `runtimes[].spec.mcp_tool_description.tools` (inside the `RemoteMCPServer` runtime's `spec` object)\n5. **Run E2E verification** through the devtunnel — call each tool and confirm the response contains `structuredContent` and `_meta.openai\u002FwidgetAccessible: true`:\n   ```bash\n   npx @modelcontextprotocol\u002Finspector@0.20.0 --cli https:\u002F\u002F\u003Ctunnel-url>\u002Fmcp --transport http --method tools\u002Fcall --tool-name \u003Ctool_name>\n   ```\n   Also verify `GET https:\u002F\u002F\u003Ctunnel-url>\u002Fhealth` returns `{\"status\":\"ok\"}`. Fix any failures before provisioning.\n\nThe MCP Inspector shows the exact tool schema from your server. Copy it completely — do not manually write or modify these definitions. This ensures `mcpPlugin.json` stays in sync with the MCP server.\n\n---\n\nBuild MCP servers that integrate with Microsoft 365 Copilot Chat and render rich interactive widgets.\n\n## Architecture\n\n```\nM365 Copilot ──▶ mcpPlugin.json ──▶ MCP Server ──▶ structuredContent ──▶ React + Fluent UI Widget\n     │              (RemoteMCPServer)    (Streamable HTTP)                  (window.openai.toolOutput)\n     │\n     └── Capabilities (People, etc.) provide data to pass to MCP tools\n```\n\n## Project Structure\n\nExample project structure, not a hard requirement but a common pattern for organizing MCP server + widget development:\n\n```\nproject\u002F\n├── appPackage\u002F\n│   ├── manifest.json           # Teams manifest (bump version on deploy)\n│   ├── declarativeAgent.json   # Agent config + capabilities\n│   ├── mcpPlugin.json          # Tool definitions with _meta\n│   └── instruction.txt         # Agent behavior instructions\n├── mcp-server\u002F\n│   ├── src\u002Findex.ts            # Server with Streamable HTTP\n│   ├── widgets\u002F                # Widget shells + React source\n│   │   ├── my-widget.html      # Minimal shell returned by resources\u002Fread\n│   │   └── src\u002Fmy-widget\u002F      # React + Fluent UI source\n│   ├── assets\u002F                 # Built widget bundles served at \u002Fassets\n│   └── package.json\n├── scripts\u002F\n│   ├── setup-devtunnel.sh      # Linux\u002FMac devtunnel setup\n│   └── setup-devtunnel.ps1     # Windows devtunnel setup\n└── env\u002F.env.local              # MCP_SERVER_URL, MCP_SERVER_DOMAIN\n```\n\n**Language note**: This shows a TypeScript project layout. For Python, replace `mcp-server\u002Fsrc\u002Findex.ts` with your Python entry point (e.g., `server.py`). For C#, use a standard .NET project structure. The `appPackage\u002F`, `widgets\u002F`, `scripts\u002F`, and `env\u002F` directories are language-agnostic.\n\n## Copilot Widget Protocol\n\nYour MCP server must implement these protocol requirements to render widgets in Copilot Chat. This applies regardless of language:\n\n1. **Streamable HTTP transport** — `\u002Fmcp` endpoint handling POST, GET, DELETE with session management\n2. **CORS headers** — Origin-checking on `\u002Fmcp` allowing `m365.cloud.microsoft` and `*.m365.cloud.microsoft`, with required MCP headers\n3. **Server capabilities** — `initialize` response must declare `resources: {}` and `tools: {}`\n4. **MCP resources** — Register widgets with `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URIs, `text\u002Fhtml+skybridge` mime type, and CSP `_meta`\n5. **Tool response format** — Return `content` (text) + `structuredContent` (widget data) + `_meta` with `openai\u002FoutputTemplate`\n6. **Widget serving** — HTTP route at `\u002Fwidgets\u002F*.html` for shell files and `\u002Fassets\u002F*` for built bundles, both with origin-checking CORS\n\nFor full protocol details, JSON shapes, and an adaptation checklist for existing MCP servers, see [references\u002Fcopilot-widget-protocol.md](references\u002Fcopilot-widget-protocol.md).\n\n## Implementation\n\n### MCP Server Pattern (TypeScript Reference)\n\nSee [references\u002Fmcp-server-pattern.md](references\u002Fmcp-server-pattern.md) for complete implementation.\n\n> For other languages, implement the requirements described in [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md) using your language's MCP SDK. See the [Language SDK References](references\u002Fcopilot-widget-protocol.md#language-sdk-references) table for SDK packages.\n\nCore requirements:\n- Expose Streamable HTTP transport on `\u002Fmcp`\n- Return `structuredContent` + `_meta` with `openai\u002FoutputTemplate`\n- Serve widgets via HTTP endpoint\n- Handle CORS for cross-origin requests\n- Handle partial data gracefully (fill in \"Unknown\" for missing fields)\n\nTool response format:\n```typescript\nreturn {\n  content: [{ type: \"text\", text: \"Summary\" }],\n  structuredContent: { \u002F* widget data *\u002F },\n  _meta: { \"openai\u002FoutputTemplate\": \"ui:\u002F\u002Fwidget\u002Fname.html\", \"openai\u002FwidgetAccessible\": true }\n};\n```\n\n### Handling Partial Data\n\nAlways normalize input data to handle missing fields:\n\n```typescript\nserver.setRequestHandler(CallToolRequestSchema, async (request: CallToolRequest) => {\n  const args = request.params.arguments as { title?: string; items?: Partial\u003CItem>[] };\n\n  \u002F\u002F Normalize data - fill in \"Unknown\" for missing fields\n  const title = args.title || \"Default Title\";\n  const items = (args.items || []).map(item => ({\n    name: item.name || \"Unknown\",\n    value: item.value || \"Unknown\",\n  }));\n\n  \u002F\u002F Build structuredContent for widget\n  const structuredContent = { title, items };\n  \u002F\u002F ...\n});\n```\n\n### Widget Pattern\n\nSee [references\u002Fwidget-patterns.md](references\u002Fwidget-patterns.md) for complete examples.\n\nCore requirements:\n- Use React + Fluent UI components (`@fluentui\u002Freact-components`)\n- Ensure widget package dependencies include `@fluentui\u002Freact-components`, `react`, and `react-dom`\n- Theme with `FluentProvider` (`webLightTheme`\u002F`webDarkTheme`) and Fluent `tokens`\n- Access data through shared hooks (e.g., `useOpenAiGlobal(\"toolOutput\")`)\n- Debug fallback: embedded mock data when `window.openai` unavailable\n- Handle \"Unknown\" values gracefully (e.g., hide action buttons)\n\n### Plugin Schema\n\nSee [references\u002Fplugin-schema.md](references\u002Fplugin-schema.md) for mcpPlugin.json format.\n\nCore requirements:\n- Schema `v2.4` with `RemoteMCPServer` runtime\n- `run_for_functions` array matching tool names\n- `_meta` in tool definitions for widget binding\n- `inputSchema` - make properties optional for flexibility, describe defaults in descriptions\n\n## DevTunnels Setup\n\n> **Local testing only.** DevTunnels are for development and testing on your machine. Before sharing the agent more broadly, deploy both the MCP server and widget assets to a hosted environment (e.g., Azure App Service, Azure Static Web Apps, or another hosting provider) and update the agent manifest URLs accordingly.\n\nDevTunnels expose your localhost MCP server to M365 Copilot using **named tunnels** for stable URLs. See [references\u002Fdevtunnels.md](references\u002Fdevtunnels.md) for setup scripts, command reference, and troubleshooting.\n\nThe setup script (`npm run tunnel` \u002F `npm run tunnel:win`):\n1. Creates a named tunnel on first run (or reuses the existing one)\n2. Starts hosting the tunnel on the configured port\n3. Updates `env\u002F.env.local` with `MCP_SERVER_URL` and `MCP_SERVER_DOMAIN` (first run only)\n4. Continues hosting the tunnel\n\n### Quick Start\n\n**Terminal 1 - Start MCP Server:**\n```bash\ncd mcp-server\nnpm install\nnpm run dev\n```\n\n**Terminal 2 - Start DevTunnel:**\n```bash\nnpm run tunnel\n# Or on Windows:\nnpm run tunnel:win\n```\n\nOn first run, provision the agent once the tunnel is up (see AGENT PROVISIONING rule). On subsequent runs the tunnel URL is stable — no re-provisioning needed unless the agent manifest changes.\n\n## Development Workflow\n\n1. **Start the MCP server** (dev mode with hot reload):\n   - TypeScript: `cd mcp-server && npm install && npm run dev`\n   - Python: `cd mcp-server && pip install -r requirements.txt && python server.py`\n   - C#: `cd mcp-server && dotnet run`\n\n2. **Start the devtunnel** (creates named tunnel on first run, reuses on subsequent runs):\n   ```bash\n   npm run tunnel\n   ```\n\n3. **Provision + test** — see AGENT PROVISIONING rule for when this is needed; bump `version` in manifest.json if Copilot doesn't reflect changes\n\n## Best Practices\n\nSee [references\u002Fbest-practices.md](references\u002Fbest-practices.md) for detailed guidance.\n\nKey points:\n1. **Rendering tools**: Accept data as input, don't fetch internally\n2. **Instructions**: Tell agent to use capabilities FIRST, then pass data to MCP tools\n3. **Themes**: Use `FluentProvider` + Fluent `tokens` for dark\u002Flight support\n4. **Debug mode**: Include fallback data for local widget testing\n5. **Partial data**: Handle missing fields with \"Unknown\" defaults\n6. **Action buttons**: Hide email\u002Fchat buttons when data is \"Unknown\"\n7. **Version bumping**: Bump manifest version when changes aren't reflected in Copilot\n","# Copilot MCP Server Development\n\n## Telemetry Tagging\n\nBefore running any `atk` CLI commands, set the session environment variable so all CLI invocations are tagged as skill-initiated:\n```bash\nexport ATK_CLI_SKILL=true\n```\nRun this once at the start of the session. All subsequent `atk` commands in the same terminal will inherit it.\n\n## ? PATH SELECTION\n\n**Before proceeding, ask the user which path they want to take using AskUserQuestion.** Both are supported for M365 Copilot widget rendering. Present the tradeoffs and let them choose:\n\n| | **OAI Apps** (this skill) | **MCP Apps Extension** (`modelcontextprotocol\u002Fext-apps`) |\n|---|---|---|\n| **Standard** | OpenAI-specific | Official MCP standard |\n| **Works in** | ChatGPT + M365 Copilot | M365 Copilot, ChatGPT, VSCode, and more |\n| **Maturity** | Battle-tested, production-ready | New official standard, growing ecosystem |\n| **Design** | OpenAI Apps SDK | MCP Apps protocol (cross-platform) |\n| **When to choose** | Existing OAI app investment | Prefer the open standard, want broadest client support |\n\n**Ask:** _\"Would you like to build an OAI app (OpenAI Apps SDK — battle-tested, works in ChatGPT and M365 Copilot) or an MCP app (new official standard — works in M365 Copilot, ChatGPT, VSCode, and more)?\"_\n\n- **OAI apps** → Continue below. This skill covers everything you need.\n- **MCP apps** → Install the `modelcontextprotocol\u002Fext-apps` plugin (see below), then use the appropriate skill from that plugin.\n\n### MCP Apps: Install ext-apps Plugin\n\nIf the user chooses MCP Apps, do this automatically (do not stop at explanation-only):\n\n1. Run `\u002Fplugin marketplace add modelcontextprotocol\u002Fext-apps`\n2. Run `\u002Fplugin install mcp-apps@mcp-apps`\n3. Confirm the plugin is available, then invoke the correct ext-apps skill based on user intent\n\nIf plugin commands are unavailable in the current environment, provide the exact commands below and ask the user to run them once, then continue by invoking the selected ext-apps skill.\n\nReference commands:\n\n```\nTo build an MCP App, install the ext-apps plugin from the marketplace:\n\n1. \u002Fplugin marketplace add modelcontextprotocol\u002Fext-apps\n2. \u002Fplugin install mcp-apps@mcp-apps\n\nThen use one of these skills from that plugin:\n- create-mcp-app      — Scaffold a new MCP App with interactive UI from scratch\n- add-app-to-server   — Add interactive UI to an existing MCP server's tools\n- migrate-oai-app     — Convert an existing OAI app to use MCP Apps\n- convert-web-app     — Turn a web app into a hybrid web + MCP App\n\nAfter installing, invoke the relevant skill to continue.\n```\n\n> **Note:** The ext-apps plugin lives in the external `modelcontextprotocol\u002Fext-apps` marketplace — it is not part of this plugin collection.\n\n**Handoff mapping after install:**\n- New MCP app from scratch → `create-mcp-app`\n- Add app UI to existing MCP server → `add-app-to-server`\n- Migrate existing OAI app → `migrate-oai-app`\n- Convert an existing web app → `convert-web-app`\n\n---\n\n## ? PROJECT DETECTION ?\n\nThis skill triggers when building MCP servers with OAI app or widget rendering for Microsoft 365 Copilot Chat. The MCP server can be written in any language that supports the MCP protocol (TypeScript, Python, C#, etc.). The agent project and MCP server may live in the same repo, separate folders, or entirely different projects.\n\n## Scenario Routing\n\n| Starting Point | What You Need | Path |\n|---------------|---------------|------|\n| **Prefer MCP Apps standard** | Cross-platform widget support (M365 Copilot, ChatGPT, VSCode, and more) | Install `modelcontextprotocol\u002Fext-apps`, then use `create-mcp-app` or `add-app-to-server` — see [Path Selection](#-path-selection) above |\n| **From scratch** (no agent, no MCP server) | Full OAI app setup | Delegate agent scaffolding to `declarative-agent-developer` first, then return here for MCP server + widgets |\n| **Existing M365 agent, new MCP server** | MCP server + widgets + mcpPlugin.json | Start at [Implementation](#implementation) |\n| **Existing MCP server, add Copilot widgets** | Widget support added to existing server | Start at [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md#adaptation-checklist-existing-mcp-server) |\n| **Language choice** (non-TypeScript) | Protocol requirements | See [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md) for what to implement, [MCP Server Pattern (TypeScript)](references\u002Fmcp-server-pattern.md) as a reference |\n\n---\n\n## ? CRITICAL EXECUTION RULES ?\n\n\n**FLUENT UI ENFORCEMENT (REQUIRED):** Widget implementations MUST use React + Fluent UI components. Before writing any widget code, the agent MUST read and follow:\n- `references\u002Fwidget-patterns.md`\n- `references\u002Fbest-practices.md`\n**FLUENT UI PACKAGE REQUIREMENT (REQUIRED):** The widget project MUST include Fluent UI dependencies before implementation. At minimum, install and keep these in the widget package dependencies:\n- `@fluentui\u002Freact-components`\n- `react`\n- `react-dom`\n\nIf any of these packages are missing, install them automatically before continuing with widget code generation.\n\nIf the generated widget does not include React entry files (for example `widgets\u002Fsrc\u002F\u003Cwidget-name>\u002Fmain.tsx` and a React component file) and Fluent imports from `@fluentui\u002Freact-components`, the task is incomplete and MUST be corrected before returning results.\n\n**NO RAW HTML-ONLY WIDGETS (DEFAULT):** Do not implement app content directly with static HTML templates and inline JS as the final widget solution. A minimal shell HTML file is allowed only as a loader for built React assets. Raw\u002Fself-contained HTML-only widgets are allowed only when the user explicitly requests a non-React prototype.\n\n**BACKGROUND PROCESSES:** MCP server and devtunnel MUST be spawned as independent OS processes — NOT run inside the agent's shell session. `isBackground: true`, `mode: \"async\"`, and `Start-Job` all run inside the agent's shell session and will be killed between messages. The only reliable approach is to spawn a detached OS process.\n\n**Windows — use `Start-Process -WindowStyle Hidden`:**\n```powershell\n# Start devtunnel\n$t = Start-Process -FilePath \"devtunnel\" `\n    -ArgumentList \"host\",\"\u003Ctunnel-name>\",\"-a\" `\n    -WindowStyle Hidden -PassThru `\n    -RedirectStandardOutput \"tunnel.log\" -RedirectStandardError \"tunnel-err.log\"\n\n# Start MCP server — use cmd.exe \u002Fc to set the working directory and inherit PATH\n$s = Start-Process -FilePath \"cmd.exe\" `\n    -ArgumentList \"\u002Fc\",\"cd \u002Fd \u003Cabs-path-to-mcp-server> && \u003Cstart-command>\" `\n    -WindowStyle Hidden -PassThru `\n    -RedirectStandardOutput \"server.log\" -RedirectStandardError \"server-err.log\"\n\n# Save PIDs so they can be stopped later\n\"$($t.Id),$($s.Id)\" | Out-File pids.txt\nWrite-Host \"Started tunnel PID $($t.Id), server PID $($s.Id)\"\n```\nTo stop: `Stop-Process -Id (Get-Content pids.txt).Split(',')` or `Stop-Process -Id \u003Cpid>`.\n\n**Linux\u002FMac — use `nohup` with `&`:**\n```bash\nnohup devtunnel host \u003Ctunnel-name> > tunnel.log 2>tunnel-err.log &\necho \"tunnel:$!\" >> pids.txt\nnohup \u003Cstart-command> > server.log 2>server-err.log &\necho \"server:$!\" >> pids.txt\n```\nTo stop: `kill $(grep -oP '\\d+' pids.txt)`.\n\nAfter starting, tail the logs to confirm both processes are up before proceeding:\n```powershell\n# Windows\nStart-Sleep 3; Get-Content tunnel.log, server.log\n```\n```bash\n# Linux\u002FMac\nsleep 3 && tail tunnel.log server.log\n```\n\n**FULL AUTOMATION:** Never tell the user to run commands manually. Install tools, authenticate, start services — do everything automatically. Only ask the user for interactive input that truly requires them (like device code confirmation during `devtunnel user login -g -d`). If a tool isn't installed, install it. If a service needs starting, start it. The user expects full automation.\n\n**PATH SELECTION (REQUIRED — STOP BEFORE ANY CODE):** You MUST use `AskUserQuestion` to ask the user whether they want OAI Apps or MCP Apps Extension before writing any code, running any commands, or making any architectural decisions.\n\n**There is no exception to this rule.** The most common failure mode is reasoning \"the user's request makes it obvious, so asking is redundant.\" This reasoning is always wrong — invoke `AskUserQuestion` regardless. A user saying \"build an MCP server with widgets\" is NOT an answer to this question. A user invoking this skill by name is NOT an answer. Only an explicit answer to the question counts. See [PATH SELECTION](#-path-selection) above for the exact question to ask.\n\n**AGENT PROVISIONING:** Re-provisioning is only required when the **agent manifest** changes (e.g., mcpPlugin.json tool definitions, MCP server URL, declarativeAgent.json, instruction.txt). MCP server code changes (tool implementations, React widget code, server logic) do **NOT** require re-provisioning the agent — running or deploying the server picks up changes automatically.\n\nWhen provisioning is needed:\n1. **Bump the version** in `manifest.json` (increment the patch version, e.g., `1.0.0` → `1.0.1`)\n2. **Deploy the agent:**\n   ```bash\n   npx -y --package @microsoft\u002Fm365agentstoolkit-cli atk provision --env local\n   ```\n\n**WIDGET TESTING LINKS:** Every time you return to the user with a result while the MCP server is running, you MUST include links to ALL widgets so they can test them locally. Format:\n```\n? Test widgets locally:\n- http:\u002F\u002Flocalhost:3001\u002Fwidgets\u002Fwidget-name.html\n- http:\u002F\u002Flocalhost:3001\u002Fwidgets\u002Fanother-widget.html\n```\nList every `.html` file in the `mcp-server\u002Fwidgets\u002F` directory (or equivalent widget folder). This helps users verify widget rendering before testing in Copilot.\n\n**AUTO-DEPLOY ON COMPLETION (REQUIRED — DO NOT SKIP):** When coding is complete, proceed automatically without waiting for the user:\n1. Start MCP server + devtunnel in the background (per BACKGROUND PROCESSES above)\n2. Run E2E verification with MCP Inspector (per MCP TOOL CONFIGURATION RULE below) — fix any failures before continuing\n3. Provision the agent if needed (per AGENT PROVISIONING above)\n4. Print a project summary in this format:\n```\n## ✅ \u003CProject Name> — Ready\n\n### Widgets\n- [widget-name.html](http:\u002F\u002Flocalhost:\u003CPORT>\u002Fwidgets\u002Fwidget-name.html)\n- [widget-name2.html](http:\u002F\u002Flocalhost:\u003CPORT>\u002Fwidgets\u002Fwidget-name2.html)\n\n### Endpoints\n- MCP server: http:\u002F\u002Flocalhost:\u003CPORT>\u002Fmcp\n- MCP via tunnel: https:\u002F\u002F\u003Ctunnel-url>\u002Fmcp\n\n### Test in Copilot\nLocal:      https:\u002F\u002Fm365.cloud.microsoft\u002Fchat\u002F?titleId={M365_TITLE_ID from env\u002F.env.local}\nOther envs: {SHARE_LINK from env\u002F.env.{environment}}\n```\n\n**AGENT PROJECT DELEGATION:** This skill builds MCP servers and widgets, NOT declarative agent projects. If the user's request involves creating or configuring the declarative agent itself (scaffolding, `m365agents.yml`, `m365agents.local.yml`, `declarativeAgent.json`, manifest lifecycle), delegate to the `declarative-agent-developer` skill.\n\n**MCP RESOURCE REGISTRATION:** Every widget MUST have a matching MCP resource. Without resources, Copilot cannot fetch widget shells through the MCP protocol and widgets will not render.\n\nFor each new widget, complete this checklist:\n1. ☐ Create a widget shell HTML file in `widgets\u002F` and a React widget entry under `widgets\u002Fsrc\u002F\u003Cwidget-name>\u002F` (see widget-patterns.md)\n2. ☐ Define a `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI constant\n3. ☐ Add a `Resource` entry to the `resources` array with:\n   - `uri`: the `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI\n   - `mimeType`: `\"text\u002Fhtml+skybridge\"`\n   - `_meta`: CSP config with `openai\u002FwidgetDomain` and `openai\u002FwidgetCSP` (from environment)\n4. ☐ Add a handler for `resources\u002Fread` that returns the widget shell HTML for this URI\n5. ☐ Add the tool with `_meta.openai\u002FoutputTemplate` pointing to the same `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URI\n6. ☐ Verify the server capabilities include `resources: {}` in the initialize response\n\n**Widget shell + asset considerations:**\n- **Preferred (React + Fluent UI)**: Resource HTML should be a minimal shell that links to built JS\u002FCSS assets served from the MCP server's `\u002Fassets\u002F` route.\n- **Exception only**: Self-contained HTML via `resources\u002Fread` is for explicit user-requested prototypes only. Default and production path is React + Fluent UI.\n\nExample shell for React build output:\n  ```html\n  \u003C!doctype html>\u003Chtml>\u003Chead>\n    \u003Cscript type=\"module\" src=\"${serverUrl}\u002Fassets\u002Fmy-widget.js\">\u003C\u002Fscript>\n    \u003Clink rel=\"stylesheet\" href=\"${serverUrl}\u002Fassets\u002Fmy-widget.css\">\n  \u003C\u002Fhead>\u003Cbody>\n    \u003Cdiv id=\"widget-root\">\u003C\u002Fdiv>\n  \u003C\u002Fbody>\u003C\u002Fhtml>\n  ```\n  Use the `WIDGET_BASE_URL` or `MCP_SERVER_URL` environment variable for the asset URL base (see mcp-server-pattern.md \"Configurable Widget Base URL\" section).\n\nSee [mcp-server-pattern.md](references\u002Fmcp-server-pattern.md) for the complete resource and asset serving patterns.\n\n---\n\n## ⚠️ MCP TOOL CONFIGURATION RULE ⚠️\n\n**NEVER manually write tool definitions in `mcpPlugin.json`.** Always use MCP Inspector to get the complete tool definitions from the running MCP server.\n\n**TOOL NAMING CONVENTION:** Tool names MUST match the pattern `^[A-Za-z0-9_]+$` (letters, numbers, and underscores only). **NEVER use hyphens (-) in tool names.** Use underscores instead (e.g., `render_profile` not `render-profile`).\n\n**MANDATORY WORKFLOW:**\n1. **Start the MCP server** (in background)\n2. **Use MCP Inspector** to get the latest tool definitions:\n   ```bash\n   npx @modelcontextprotocol\u002Finspector@0.20.0 --cli https:\u002F\u002Fmy-mcp-server.example.com --transport http --method tools\u002Flist\n   ```\n3. **Copy the COMPLETE tool definition** from the inspector (including `name`, `description`, `inputSchema`, `_meta`, `annotations`, `title`)\n4. **Paste into `mcpPlugin.json`** under `runtimes[].spec.mcp_tool_description.tools` (inside the `RemoteMCPServer` runtime's `spec` object)\n5. **Run E2E verification** through the devtunnel — call each tool and confirm the response contains `structuredContent` and `_meta.openai\u002FwidgetAccessible: true`:\n   ```bash\n   npx @modelcontextprotocol\u002Finspector@0.20.0 --cli https:\u002F\u002F\u003Ctunnel-url>\u002Fmcp --transport http --method tools\u002Fcall --tool-name \u003Ctool_name>\n   ```\n   Also verify `GET https:\u002F\u002F\u003Ctunnel-url>\u002Fhealth` returns `{\"status\":\"ok\"}`. Fix any failures before provisioning.\n\nThe MCP Inspector shows the exact tool schema from your server. Copy it completely — do not manually write or modify these definitions. This ensures `mcpPlugin.json` stays in sync with the MCP server.\n\n---\n\nBuild MCP servers that integrate with Microsoft 365 Copilot Chat and render rich interactive widgets.\n\n## Architecture\n\n```\nM365 Copilot ──▶ mcpPlugin.json ──▶ MCP Server ──▶ structuredContent ──▶ React + Fluent UI Widget\n     │              (RemoteMCPServer)    (Streamable HTTP)                  (window.openai.toolOutput)\n     │\n     └── Capabilities (People, etc.) provide data to pass to MCP tools\n```\n\n## Project Structure\n\nExample project structure, not a hard requirement but a common pattern for organizing MCP server + widget development:\n\n```\nproject\u002F\n├── appPackage\u002F\n│   ├── manifest.json           # Teams manifest (bump version on deploy)\n│   ├── declarativeAgent.json   # Agent config + capabilities\n│   ├── mcpPlugin.json          # Tool definitions with _meta\n│   └── instruction.txt         # Agent behavior instructions\n├── mcp-server\u002F\n│   ├── src\u002Findex.ts            # Server with Streamable HTTP\n│   ├── widgets\u002F                # Widget shells + React source\n│   │   ├── my-widget.html      # Minimal shell returned by resources\u002Fread\n│   │   └── src\u002Fmy-widget\u002F      # React + Fluent UI source\n│   ├── assets\u002F                 # Built widget bundles served at \u002Fassets\n│   └── package.json\n├── scripts\u002F\n│   ├── setup-devtunnel.sh      # Linux\u002FMac devtunnel setup\n│   └── setup-devtunnel.ps1     # Windows devtunnel setup\n└── env\u002F.env.local              # MCP_SERVER_URL, MCP_SERVER_DOMAIN\n```\n\n**Language note**: This shows a TypeScript project layout. For Python, replace `mcp-server\u002Fsrc\u002Findex.ts` with your Python entry point (e.g., `server.py`). For C#, use a standard .NET project structure. The `appPackage\u002F`, `widgets\u002F`, `scripts\u002F`, and `env\u002F` directories are language-agnostic.\n\n## Copilot Widget Protocol\n\nYour MCP server must implement these protocol requirements to render widgets in Copilot Chat. This applies regardless of language:\n\n1. **Streamable HTTP transport** — `\u002Fmcp` endpoint handling POST, GET, DELETE with session management\n2. **CORS headers** — Origin-checking on `\u002Fmcp` allowing `m365.cloud.microsoft` and `*.m365.cloud.microsoft`, with required MCP headers\n3. **Server capabilities** — `initialize` response must declare `resources: {}` and `tools: {}`\n4. **MCP resources** — Register widgets with `ui:\u002F\u002Fwidget\u002F\u003Cname>.html` URIs, `text\u002Fhtml+skybridge` mime type, and CSP `_meta`\n5. **Tool response format** — Return `content` (text) + `structuredContent` (widget data) + `_meta` with `openai\u002FoutputTemplate`\n6. **Widget serving** — HTTP route at `\u002Fwidgets\u002F*.html` for shell files and `\u002Fassets\u002F*` for built bundles, both with origin-checking CORS\n\nFor full protocol details, JSON shapes, and an adaptation checklist for existing MCP servers, see [references\u002Fcopilot-widget-protocol.md](references\u002Fcopilot-widget-protocol.md).\n\n## Implementation\n\n### MCP Server Pattern (TypeScript Reference)\n\nSee [references\u002Fmcp-server-pattern.md](references\u002Fmcp-server-pattern.md) for complete implementation.\n\n> For other languages, implement the requirements described in [Copilot Widget Protocol](references\u002Fcopilot-widget-protocol.md) using your language's MCP SDK. See the [Language SDK References](references\u002Fcopilot-widget-protocol.md#language-sdk-references) table for SDK packages.\n\nCore requirements:\n- Expose Streamable HTTP transport on `\u002Fmcp`\n- Return `structuredContent` + `_meta` with `openai\u002FoutputTemplate`\n- Serve widgets via HTTP endpoint\n- Handle CORS for cross-origin requests\n- Handle partial data gracefully (fill in \"Unknown\" for missing fields)\n\nTool response format:\n```typescript\nreturn {\n  content: [{ type: \"text\", text: \"Summary\" }],\n  structuredContent: { \u002F* widget data *\u002F },\n  _meta: { \"openai\u002FoutputTemplate\": \"ui:\u002F\u002Fwidget\u002Fname.html\", \"openai\u002FwidgetAccessible\": true }\n};\n```\n\n### Handling Partial Data\n\nAlways normalize input data to handle missing fields:\n\n```typescript\nserver.setRequestHandler(CallToolRequestSchema, async (request: CallToolRequest) => {\n  const args = request.params.arguments as { title?: string; items?: Partial\u003CItem>[] };\n\n  \u002F\u002F Normalize data - fill in \"Unknown\" for missing fields\n  const title = args.title || \"Default Title\";\n  const items = (args.items || []).map(item => ({\n    name: item.name || \"Unknown\",\n    value: item.value || \"Unknown\",\n  }));\n\n  \u002F\u002F Build structuredContent for widget\n  const structuredContent = { title, items };\n  \u002F\u002F ...\n});\n```\n\n### Widget Pattern\n\nSee [references\u002Fwidget-patterns.md](references\u002Fwidget-patterns.md) for complete examples.\n\nCore requirements:\n- Use React + Fluent UI components (`@fluentui\u002Freact-components`)\n- Ensure widget package dependencies include `@fluentui\u002Freact-components`, `react`, and `react-dom`\n- Theme with `FluentProvider` (`webLightTheme`\u002F`webDarkTheme`) and Fluent `tokens`\n- Access data through shared hooks (e.g., `useOpenAiGlobal(\"toolOutput\")`)\n- Debug fallback: embedded mock data when `window.openai` unavailable\n- Handle \"Unknown\" values gracefully (e.g., hide action buttons)\n\n### Plugin Schema\n\nSee [references\u002Fplugin-schema.md](references\u002Fplugin-schema.md) for mcpPlugin.json format.\n\nCore requirements:\n- Schema `v2.4` with `RemoteMCPServer` runtime\n- `run_for_functions` array matching tool names\n- `_meta` in tool definitions for widget binding\n- `inputSchema` - make properties optional for flexibility, describe defaults in descriptions\n\n## DevTunnels Setup\n\n> **Local testing only.** DevTunnels are for development and testing on your machine. Before sharing the agent more broadly, deploy both the MCP server and widget assets to a hosted environment (e.g., Azure App Service, Azure Static Web Apps, or another hosting provider) and update the agent manifest URLs accordingly.\n\nDevTunnels expose your localhost MCP server to M365 Copilot using **named tunnels** for stable URLs. See [references\u002Fdevtunnels.md](references\u002Fdevtunnels.md) for setup scripts, command reference, and troubleshooting.\n\nThe setup script (`npm run tunnel` \u002F `npm run tunnel:win`):\n1. Creates a named tunnel on first run (or reuses the existing one)\n2. Starts hosting the tunnel on the configured port\n3. Updates `env\u002F.env.local` with `MCP_SERVER_URL` and `MCP_SERVER_DOMAIN` (first run only)\n4. Continues hosting the tunnel\n\n### Quick Start\n\n**Terminal 1 - Start MCP Server:**\n```bash\ncd mcp-server\nnpm install\nnpm run dev\n```\n\n**Terminal 2 - Start DevTunnel:**\n```bash\nnpm run tunnel\n# Or on Windows:\nnpm run tunnel:win\n```\n\nOn first run, provision the agent once the tunnel is up (see AGENT PROVISIONING rule). On subsequent runs the tunnel URL is stable — no re-provisioning needed unless the agent manifest changes.\n\n## Development Workflow\n\n1. **Start the MCP server** (dev mode with hot reload):\n   - TypeScript: `cd mcp-server && npm install && npm run dev`\n   - Python: `cd mcp-server && pip install -r requirements.txt && python server.py`\n   - C#: `cd mcp-server && dotnet run`\n\n2. **Start the devtunnel** (creates named tunnel on first run, reuses on subsequent runs):\n   ```bash\n   npm run tunnel\n   ```\n\n3. **Provision + test** — see AGENT PROVISIONING rule for when this is needed; bump `version` in manifest.json if Copilot doesn't reflect changes\n\n## Best Practices\n\nSee [references\u002Fbest-practices.md](references\u002Fbest-practices.md) for detailed guidance.\n\nKey points:\n1. **Rendering tools**: Accept data as input, don't fetch internally\n2. **Instructions**: Tell agent to use capabilities FIRST, then pass data to MCP tools\n3. **Themes**: Use `FluentProvider` + Fluent `tokens` for dark\u002Flight support\n4. **Debug mode**: Include fallback data for local widget testing\n5. **Partial data**: Handle missing fields with \"Unknown\" defaults\n6. **Action buttons**: Hide email\u002Fchat buttons when data is \"Unknown\"\n7. **Version bumping**: Bump manifest version when changes aren't reflected in Copilot\n",{"name":5,"description":7},"main","3f5b461b2314e01c400564051e92469114c5b68f",".github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer",368,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills","https:\u002F\u002Fmicrosoft.github.io\u002Fskills\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 02:08:41",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add microsoft\u002Fskills --skill ui-widget-developer",{"tool":77,"command":78},"bunx","bunx skills add microsoft\u002Fskills --skill ui-widget-developer",{"tool":80,"command":81},"pnpm","pnpm dlx skills add microsoft\u002Fskills --skill ui-widget-developer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002FSKILL.md",true,[85,91,95,99,103,107],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fbest-practices.md","REFERENCE","参考文档",12269,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fbest-practices.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fcopilot-widget-protocol.md",11774,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fcopilot-widget-protocol.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fdevtunnels.md",11867,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fdevtunnels.md",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fmcp-server-pattern.md",14682,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fmcp-server-pattern.md",{"path":104,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fplugin-schema.md",6964,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fplugin-schema.md",{"path":108,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fwidget-patterns.md",6345,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fplugins\u002Fmicrosoft-365-agents-toolkit\u002Fskills\u002Fui-widget-developer\u002Freferences\u002Fwidget-patterns.md",[112,137,174,199,219,255],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":119,"publishedAt":56},"01M69B4JCRQV5SPXAFCKXQRV0H","skill-creator","Guide for creating effective skills for AI coding agents working with Azure SDKs and Microsoft Foundry services. Use when creating new skills or updating existing skills.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fskill-creator\u002FSKILL.md",[118],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[120,121,122,9,123,124,125,126,127,128,129,130,131,132,133,134,135,37,136],"skill creator","creator","coding agents","foundry","microsoft foundry","ai coding agents","azure","services","coding","guide","use","ai coding","with","sdks","for","Existing","new",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":153,"publishedAt":56},"01M69B4FD57V1MYKRWAJJECTZ7","podcast-generation","Generate AI-powered podcast-style audio narratives using Azure OpenAI's GPT Realtime Mini model via WebSocket. Use when building text-to-speech features, audio narrative generation, podcast creation from content, or integrating with Azure OpenAI Realtime API for real audio output. Covers full-stack implementation from React frontend to Python FastAPI backend with WebSocket streaming.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpodcast-generation\u002FSKILL.md",[143,146,149,152],{"categoryNo":144,"categoryName":145,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":147,"categoryName":148,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":150,"categoryName":151,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[154,155,156,157,158,51,159,126,160,161,162,163,164,165,166,167,168,169,170,171,172,37,173],"podcast generation","podcast","generation","frontend","python","realtime","azure openai","generate","streaming","api","Audio","stack","text","model","fastapi","creation","python fastapi","narrative","features","fastapi backend",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":181,"publishedAt":56},"01M69B4CYPM5SESY5ZWEFDXEQZ","microsoft-docs","Understand Microsoft technologies by querying official documentation. Use whenever the user asks how something works, wants tutorials, needs configuration options, limits, quotas, or best practices for any Microsoft technology (Azure, .NET, M365, Windows, Power Platform, etc.)—even if they don't mention \"docs.\" If the question is about understanding a concept rather than writing code, this is the right skill.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fmicrosoft-docs\u002FSKILL.md",[180],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[182,9,183,47,184,185,54,186,187,188,189,126,190,191,192,130,193,74,194,195,196,197,198,134],"docs","microsoft docs","writing","cli","windows","power platform","official","documentation","learn","best practices","question","power","back","technology","platform","learn mcp","concept",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":203,"categories":204,"keywords":206,"publishedAt":56},"01M69B49C3YPD1ZJ3NC0HPCY58","mcp-builder","Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP), Node\u002FTypeScript (MCP SDK), or C#\u002F.NET (Microsoft MCP SDK).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fmcp-builder\u002FSKILL.md",[205],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[47,207,208,209,158,210,55,211,9,212,213,167,214,215,129,130,216,217,218,132,134,37],"mcp builder","builder","typescript","llms","model context protocol","fastmcp","Tools","node","context","integrate","mcp sdk","building mcp servers",{"skillNo":220,"name":221,"nameZh":6,"description":222,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":223,"categories":224,"keywords":235,"publishedAt":56},"01M69B467A7CDMFQ0T6Q0ZA12Q","kql","KQL language expertise for writing correct, efficient Kusto Query Language queries. Covers syntax gotchas, join patterns, dynamic types, datetime pitfalls, regex patterns, serialization, memory management, result-size discipline, and advanced functions (geo, vector, graph). USE THIS SKILL whenever writing, debugging, or reviewing KQL queries — even simple ones — because the gotchas section prevents the most common errors that waste tool calls and cause expensive retry cascades. Trigger on: KQL, Kusto, ADX, Azure Data Explorer, Fabric Real-Time Intelligence, EventHouse, Log Analytics, log analysis, data exploration, time series, anomaly detection, summarize, where clause, join, extend, project, let statement, parse operator, extract function, any mention of pipe-forward query syntax.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fkql\u002FSKILL.md",[225,228,229,232],{"categoryNo":226,"categoryName":227,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":230,"categoryName":231,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000033","数据分析师",{"categoryNo":233,"categoryName":234,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[221,184,236,237,238,126,239,240,241,242,243,244,245,246,247,248,249,250,251,134,252,253,254],"summarize","memory","analytics","vector","time series","tool","discipline","log","geo","exploration","pipe","time","project","regex","join","datetime","section","anomaly","parse",{"skillNo":256,"name":257,"nameZh":6,"description":258,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":259,"categories":260,"keywords":261,"publishedAt":56},"01M69B44HJQ7897EZ7NE7DWQX3","github-issue-creator","Convert raw notes, error logs, voice dictation, or screenshots into crisp GitHub-flavored markdown issue reports. Use when the user pastes bug info, error messages, or informal descriptions and wants a structured GitHub issue. Supports images\u002FGIFs for visual evidence.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fskills\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fgithub-issue-creator\u002FSKILL.md",[],[262,263,264,265,121,266,267,268,269,270,271,272,130,273,274,275,276,277,278,134,37],"github","github issue creator","github issue","issue","issue creator","screenshots","notes","logs","error messages","messages","convert","evidence","reports","images","info","visual","error"]