[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718AFVRZR4QVCVAK67D5WTA":3,"skill-same:01M718AFVRZR4QVCVAK67D5WTA":104},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":62,"ownerDescription":6,"updatedAt":63,"install":64,"resources":77},"01M718AFVRZR4QVCVAK67D5WTA","build-mcp-app",null,"This skill should be used when the user wants to build an \"MCP app\", add \"interactive UI\" or \"widgets\" to an MCP server, \"render components in chat\", build \"MCP UI resources\", make a tool that shows a \"form\", \"picker\", \"dashboard\" or \"confirmation dialog\" inline in the conversation, or mentions \"apps SDK\" in the context of MCP. Use AFTER the build-mcp-server skill has settled the deployment model, or when the user already knows they want UI widgets.","anthropics\u002Fclaude-plugins-official","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M7188MR49TZ9N2ZKPXJ7M7HY",46789,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"build mcp","build mcp app","build","MCP","app","conversation","when","mcp-server","inline","render","resources","apps","widgets","confirmation","dialog","model","server","components","dashboard","mcp server","2026-11-10 10:12:30",false,"---\nname: build-mcp-app\ndescription: This skill should be used when the user wants to build an \"MCP app\", add \"interactive UI\" or \"widgets\" to an MCP server, \"render components in chat\", build \"MCP UI resources\", make a tool that shows a \"form\", \"picker\", \"dashboard\" or \"confirmation dialog\" inline in the conversation, or mentions \"apps SDK\" in the context of MCP. Use AFTER the build-mcp-server skill has settled the deployment model, or when the user already knows they want UI widgets.\nversion: 0.1.0\n---\n\n# Build an MCP App (Interactive UI Widgets)\n\nAn MCP app is a standard MCP server that **also serves UI resources** — interactive components rendered inline in the chat surface. Build once, runs in Claude *and* ChatGPT and any other host that implements the apps surface.\n\nThe UI layer is **additive**. Under the hood it's still tools, resources, and the same wire protocol. If you haven't built a plain MCP server before, the `build-mcp-server` skill covers the base layer. This skill adds widgets on top.\n\n> **Testing in Claude:** Add the server as a custom connector in claude.ai (via a Cloudflare tunnel for local dev) — this exercises the real iframe sandbox and `hostContext`. See https:\u002F\u002Fclaude.com\u002Fdocs\u002Fconnectors\u002Fbuilding\u002Ftesting.\n\n## Claude host specifics\n\n| `_meta.ui.*` key | Where | Effect |\n|---|---|---|\n| `resourceUri` | tool | Which `ui:\u002F\u002F` resource the host renders for this tool's results. |\n| `visibility: [\"app\"]` | tool | Hide a widget-only helper tool (e.g. geometry\u002Fimage fetcher called via `callServerTool`) from Claude's tool list. |\n| `prefersBorder: false` | resource | Drop the host's outer card border (mobile). |\n| `csp.{connectDomains, resourceDomains, baseUriDomains}` | resource | Declare external origins; default is block-all. `frameDomains` is currently restricted in Claude. |\n\n- `hostContext.safeAreaInsets: {top, right, bottom, left}` (px) — honor these for notches and the composer overlay.\n- Directory submission requires OAuth or **authless** (`none`) — static bearer is private-deploy only and blocks listing — plus tool `annotations` and 3–5 PNG screenshots; see `references\u002Fdirectory-checklist.md`.\n\n---\n\n## When a widget beats plain text\n\nDon't add UI for its own sake — most tools are fine returning text or JSON. Add a widget when one of these is true:\n\n| Signal | Widget type |\n|---|---|\n| Tool needs structured input Claude can't reliably infer | Form |\n| User must pick from a list Claude can't rank (files, contacts, records) | Picker \u002F table |\n| Destructive or billable action needs explicit confirmation | Confirm dialog |\n| Output is spatial or visual (charts, maps, diffs, previews) | Display widget |\n| Long-running job the user wants to watch | Progress \u002F live status |\n\nIf none apply, skip the widget. Text is faster to build and faster for the user.\n\n---\n\n## Widgets vs Elicitation — route correctly\n\nBefore building a widget, check if **elicitation** covers it. Elicitation is spec-native, zero UI code, works in any compliant host.\n\n| Need | Elicitation | Widget |\n|---|---|---|\n| Confirm yes\u002Fno | ✅ | overkill |\n| Pick from short enum | ✅ | overkill |\n| Fill a flat form (name, email, date) | ✅ | overkill |\n| Pick from a large\u002Fsearchable list | ❌ (no scroll\u002Fsearch) | ✅ |\n| Visual preview before choosing | ❌ | ✅ |\n| Chart \u002F map \u002F diff view | ❌ | ✅ |\n| Live-updating progress | ❌ | ✅ |\n\nIf elicitation covers it, use it. See `..\u002Fbuild-mcp-server\u002Freferences\u002Felicitation.md`.\n\n---\n\n## Architecture: two deployment shapes\n\n### Remote MCP app (most common)\n\nHosted streamable-HTTP server. Widget templates are served as **resources**; tool results reference them. The host fetches the resource, renders it in an iframe sandbox, and brokers messages between the widget and Claude.\n\n```\n┌──────────┐  tools\u002Fcall   ┌────────────┐\n│  Claude  │─────────────> │ MCP server │\n│   host   │\u003C── result ────│  (remote)  │\n│          │  + widget ref │            │\n│          │               │            │\n│          │ resources\u002Fread│            │\n│          │─────────────> │  widget    │\n│ ┌──────┐ │\u003C── template ──│  HTML\u002FJS   │\n│ │iframe│ │               └────────────┘\n│ │widget│ │\n│ └──────┘ │\n└──────────┘\n```\n\n### MCPB-packaged MCP app (local + UI)\n\nSame widget mechanism, but the server runs locally inside an MCPB bundle. Use this when the widget needs to drive a **local** application — e.g., a file picker that browses the actual local disk, a dialog that controls a desktop app.\n\nFor MCPB packaging mechanics, defer to the **`build-mcpb`** skill. Everything below applies to both shapes.\n\n---\n\n## How widgets attach to tools\n\nA widget-enabled tool has **two separate registrations**:\n\n1. **The tool** declares a UI resource via `_meta.ui.resourceUri`. Its handler returns plain text\u002FJSON — NOT the HTML.\n2. **The resource** is registered separately and serves the HTML.\n\nWhen Claude calls the tool, the host sees `_meta.ui.resourceUri`, fetches that resource, renders it in an iframe, and pipes the tool's return value into the iframe via the `ontoolresult` event.\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }\n  from \"@modelcontextprotocol\u002Fext-apps\u002Fserver\";\nimport { z } from \"zod\";\n\nconst server = new McpServer({ name: \"contacts\", version: \"1.0.0\" });\n\n\u002F\u002F 1. The tool — returns DATA, declares which UI to show\nregisterAppTool(server, \"pick_contact\", {\n  description: \"Open an interactive contact picker\",\n  annotations: { title: \"Pick Contact\", readOnlyHint: true },\n  inputSchema: { filter: z.string().optional() },\n  _meta: { ui: { resourceUri: \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\" } },\n}, async ({ filter }) => {\n  const contacts = await db.contacts.search(filter);\n  \u002F\u002F Plain JSON — the widget receives this via ontoolresult\n  return { content: [{ type: \"text\", text: JSON.stringify(contacts) }] };\n});\n\n\u002F\u002F 2. The resource — serves the HTML\nregisterAppResource(\n  server,\n  \"Contact Picker\",\n  \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\",\n  {},\n  async () => ({\n    contents: [{\n      uri: \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\",\n      mimeType: RESOURCE_MIME_TYPE,\n      text: pickerHtml,  \u002F\u002F your HTML string\n    }],\n  }),\n);\n```\n\nThe URI scheme `ui:\u002F\u002F` is convention. The mime type MUST be `RESOURCE_MIME_TYPE` (`\"text\u002Fhtml;profile=mcp-app\"`) — this is how the host knows to render it as an interactive iframe, not just display the source.\n\n---\n\n## Widget runtime — the `App` class\n\nInside the iframe, your script talks to the host via the `App` class from `@modelcontextprotocol\u002Fext-apps`. This is a **persistent bidirectional connection** — the widget stays alive as long as the conversation is active, receiving new tool results and sending user actions.\n\n```html\n\u003Cscript type=\"module\">\n  \u002F* ext-apps bundle inlined at build time → globalThis.ExtApps *\u002F\n  \u002F*__EXT_APPS_BUNDLE__*\u002F\n  const { App } = globalThis.ExtApps;\n\n  const app = new App({ name: \"ContactPicker\", version: \"1.0.0\" }, {});\n\n  \u002F\u002F Set handlers BEFORE connecting\n  app.ontoolresult = ({ content }) => {\n    const contacts = JSON.parse(content[0].text);\n    render(contacts);\n  };\n\n  await app.connect();\n\n  \u002F\u002F Later, when the user clicks something:\n  function onPick(contact) {\n    app.sendMessage({\n      role: \"user\",\n      content: [{ type: \"text\", text: `Selected contact: ${contact.id}` }],\n    });\n  }\n\u003C\u002Fscript>\n```\n\nThe `\u002F*__EXT_APPS_BUNDLE__*\u002F` placeholder gets replaced by the server at startup with the contents of `@modelcontextprotocol\u002Fext-apps\u002Fapp-with-deps` — see `references\u002Fiframe-sandbox.md` for why this is necessary and the rewrite snippet. **Do not** `import { App } from \"https:\u002F\u002Fesm.sh\u002F...\"`; the iframe's CSP blocks the transitive dependency fetches and the widget renders blank.\n\n| Method | Direction | Use for |\n|---|---|---|\n| `app.ontoolresult = fn` | Host → widget | Receive the tool's return value |\n| `app.ontoolinput = fn` | Host → widget | Receive the tool's input args (what Claude passed) |\n| `app.sendMessage({...})` | Widget → host | Inject a message into the conversation |\n| `app.updateModelContext({...})` | Widget → host | Update context silently (no visible message) |\n| `app.callServerTool({name, arguments})` | Widget → server | Call another tool on your server |\n| `app.openLink({url})` | Widget → host | Open a URL in a new tab (sandbox blocks `window.open`) |\n| `app.getHostContext()` \u002F `app.onhostcontextchanged` | Host → widget | Theme, host CSS vars, `containerDimensions`, `displayMode`, `deviceCapabilities` |\n| `app.requestDisplayMode({mode})` | Widget → host | Ask for `inline` \u002F `pip` \u002F `fullscreen` |\n| `app.downloadFile({name, mimeType, content})` | Widget → host | Host-mediated download (base64 content) |\n| `new App(info, caps, {autoResize: true})` | — | Iframe height tracks rendered content |\n\n`sendMessage` is the typical \"user picked something, tell Claude\" path. `updateModelContext` is for state that Claude should know about but shouldn't clutter the chat. `openLink` is **required** for any outbound navigation — `window.open` and `\u003Ca target=\"_blank\">` are blocked by the sandbox attribute.\n\n**What widgets cannot do:**\n- Access the host page's DOM, cookies, or storage\n- Make network calls to arbitrary origins (CSP-restricted — route through `callServerTool`)\n- Open popups or navigate directly — use `app.openLink({url})`\n- Load remote images reliably — inline as `data:` URLs server-side\n\nKeep widgets **small and single-purpose**. A picker picks. A chart displays. Don't build a whole sub-app inside the iframe — split it into multiple tools with focused widgets.\n\n---\n\n## Scaffold: minimal picker widget\n\n**Install:**\n\n```bash\nnpm install @modelcontextprotocol\u002Fsdk @modelcontextprotocol\u002Fext-apps zod express\n```\n\n**Server (`src\u002Fserver.ts`):**\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { StreamableHTTPServerTransport } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002FstreamableHttp.js\";\nimport { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }\n  from \"@modelcontextprotocol\u002Fext-apps\u002Fserver\";\nimport express from \"express\";\nimport { readFileSync } from \"node:fs\";\nimport { createRequire } from \"node:module\";\nimport { z } from \"zod\";\n\nconst require = createRequire(import.meta.url);\nconst server = new McpServer({ name: \"contact-picker\", version: \"1.0.0\" });\n\n\u002F\u002F Inline the ext-apps browser bundle into the widget HTML.\n\u002F\u002F The iframe CSP blocks CDN script fetches — bundling is mandatory.\nconst bundle = readFileSync(\n  require.resolve(\"@modelcontextprotocol\u002Fext-apps\u002Fapp-with-deps\"), \"utf8\",\n).replace(\u002Fexport\\{([^}]+)\\};?\\s*$\u002F, (_, body) =>\n  \"globalThis.ExtApps={\" +\n  body.split(\",\").map((p) => {\n    const [local, exported] = p.split(\" as \").map((s) => s.trim());\n    return `${exported ?? local}:${local}`;\n  }).join(\",\") + \"};\",\n);\nconst pickerHtml = readFileSync(\".\u002Fwidgets\u002Fpicker.html\", \"utf8\")\n  .replace(\"\u002F*__EXT_APPS_BUNDLE__*\u002F\", () => bundle);\n\nregisterAppTool(server, \"pick_contact\", {\n  description: \"Open an interactive contact picker. User selects one contact.\",\n  annotations: { title: \"Pick Contact\", readOnlyHint: true },\n  inputSchema: { filter: z.string().optional().describe(\"Name\u002Femail prefix filter\") },\n  _meta: { ui: { resourceUri: \"ui:\u002F\u002Fwidgets\u002Fpicker.html\" } },\n}, async ({ filter }) => {\n  const contacts = await db.contacts.search(filter ?? \"\");\n  return { content: [{ type: \"text\", text: JSON.stringify(contacts) }] };\n});\n\nregisterAppResource(server, \"Contact Picker\", \"ui:\u002F\u002Fwidgets\u002Fpicker.html\", {},\n  async () => ({\n    contents: [{ uri: \"ui:\u002F\u002Fwidgets\u002Fpicker.html\", mimeType: RESOURCE_MIME_TYPE, text: pickerHtml }],\n  }),\n);\n\nconst app = express();\napp.use(express.json());\napp.post(\"\u002Fmcp\", async (req, res) => {\n  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });\n  res.on(\"close\", () => transport.close());\n  await server.connect(transport);\n  await transport.handleRequest(req, res, req.body);\n});\napp.listen(process.env.PORT ?? 3000);\n```\n\nFor local-only widget apps (driving a desktop app, reading local files), swap the transport to `StdioServerTransport` and package via the `build-mcpb` skill.\n\n**Widget (`widgets\u002Fpicker.html`):**\n\n```html\n\u003C!doctype html>\n\u003Cmeta charset=\"utf-8\" \u002F>\n\u003Cstyle>\n  body { font: 14px system-ui; margin: 0; }\n  ul { list-style: none; padding: 0; margin: 0; max-height: 300px; overflow-y: auto; }\n  li { padding: 10px 14px; cursor: pointer; border-bottom: 1px solid #eee; }\n  li:hover { background: #f5f5f5; }\n  .sub { color: #666; font-size: 12px; }\n\u003C\u002Fstyle>\n\u003Cul id=\"list\">\u003C\u002Ful>\n\u003Cscript type=\"module\">\n\u002F*__EXT_APPS_BUNDLE__*\u002F\nconst { App } = globalThis.ExtApps;\n(async () => {\n  const app = new App({ name: \"ContactPicker\", version: \"1.0.0\" }, {});\n  const ul = document.getElementById(\"list\");\n\n  app.ontoolresult = ({ content }) => {\n    const contacts = JSON.parse(content[0].text);\n    ul.innerHTML = \"\";\n    for (const c of contacts) {\n      const li = document.createElement(\"li\");\n      li.innerHTML = `\u003Cdiv>${c.name}\u003C\u002Fdiv>\u003Cdiv class=\"sub\">${c.email}\u003C\u002Fdiv>`;\n      li.addEventListener(\"click\", () => {\n        app.sendMessage({\n          role: \"user\",\n          content: [{ type: \"text\", text: `Selected contact: ${c.id} (${c.name})` }],\n        });\n      });\n      ul.append(li);\n    }\n  };\n\n  await app.connect();\n})();\n\u003C\u002Fscript>\n```\n\nSee `references\u002Fwidget-templates.md` for more widget shapes.\n\n---\n\n## Design notes that save you a rewrite\n\n**One widget per tool.** Resist the urge to build one mega-widget that does everything. One tool → one focused widget → one clear result shape. Claude reasons about these far better.\n\n**Tool description must mention the widget.** Claude only sees the tool description when deciding what to call. \"Opens an interactive picker\" in the description is what makes Claude reach for it instead of guessing an ID.\n\n**Widgets are optional at runtime.** Hosts that don't support the apps surface simply ignore `_meta.ui` and render the tool's text content normally. Since your tool handler already returns meaningful text\u002FJSON (the widget's data), degradation is automatic — Claude sees the data directly instead of via the widget.\n\n**Don't block on widget results for read-only tools.** A widget that just *displays* data (chart, preview) shouldn't require a user action to complete. Return the display widget *and* a text summary in the same result so Claude can continue reasoning without waiting.\n\n**Layout-fork by item count, not by tool count.** If one use case is \"show one result in detail\" and another is \"show many results side-by-side\", don't make two tools — make one tool that accepts `items[]`, and let the widget pick a layout: `items.length === 1` → detail view, `> 1` → carousel. Keeps the server schema simple and lets Claude decide count naturally.\n\n**Put Claude's reasoning in the payload.** A short `note` field on each item (why Claude picked it) rendered as a callout on the card gives users the reasoning inline with the choice. Mention this field in the tool description so Claude populates it.\n\n**Normalize image shapes server-side.** If your data source returns images with wildly varying aspect ratios, rewrite to a predictable variant (e.g. square-bounded) *before* fetching for the data-URL inline. Then give the widget's image container a fixed `aspect-ratio` + `object-fit: contain` so everything sits centered.\n\n**Follow host theme.** `app.getHostContext()?.theme` (after `connect()`) plus `app.onhostcontextchanged` for live updates. Toggle a `.dark` class on `\u003Chtml>`, keep colors in CSS custom props with a `:root.dark {}` override block, set `color-scheme`. Disable `mix-blend-mode: multiply` in dark — it makes images vanish.\n\n---\n\n## Testing\n\n**Claude Desktop** — current builds still require the `command`\u002F`args` config shape (no native `\"type\": \"http\"`). Wrap with `mcp-remote` and force `http-only` transport so the SSE probe doesn't swallow widget-capability negotiation:\n\n```json\n{\n  \"mcpServers\": {\n    \"my-server\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"http:\u002F\u002Flocalhost:3000\u002Fmcp\",\n               \"--allow-http\", \"--transport\", \"http-only\"]\n    }\n  }\n}\n```\n\nDesktop caches UI resources aggressively. After editing widget HTML, **fully quit** (⌘Q \u002F Alt+F4, not window-close) and relaunch to force a cold resource re-fetch.\n\n**Headless JSON-RPC loop** — fast iteration without clicking through Desktop:\n\n```bash\n# test.jsonl — one JSON-RPC message per line\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-06-18\",\"capabilities\":{},\"clientInfo\":{\"name\":\"t\",\"version\":\"0\"}}}\n{\"jsonrpc\":\"2.0\",\"method\":\"notifications\u002Finitialized\"}\n{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools\u002Flist\"}\n{\"jsonrpc\":\"2.0\",\"id\":3,\"method\":\"tools\u002Fcall\",\"params\":{\"name\":\"your_tool\",\"arguments\":{...}}}\n\n(cat test.jsonl; sleep 10) | npx mcp-remote http:\u002F\u002Flocalhost:3000\u002Fmcp --allow-http\n```\n\nThe `sleep` keeps stdin open long enough to collect all responses. Parse the jsonl output with `jq` or a Python one-liner.\n\n**Widget dev loop** — avoid the ⌘Q-relaunch cycle entirely by serving the inlined widget HTML at a plain GET route with a fake `ExtApps` shim that fires `ontoolresult` from a query param:\n\n```ts\napp.get(\"\u002Fwidget-preview\", (_req, res) => {\n  const shim = `globalThis.ExtApps={applyHostStyleVariables:()=>{},App:class{\n    constructor(){this.h={}} ontoolresult;onhostcontextchanged;\n    async connect(){const p=new URLSearchParams(location.search).get(\"payload\");\n      if(p)this.ontoolresult?.({content:[{type:\"text\",text:p}]});}\n    getHostContext(){return{theme:\"light\"}}\n    sendMessage(m){console.log(\"sendMessage\",m)} updateModelContext(){}\n    callServerTool(){return Promise.resolve({content:[]})} openLink(){} downloadFile(){}\n  }};`;\n  res.type(\"html\").send(widgetHtml.replace(\"\u002F*__EXT_APPS_BUNDLE__*\u002F\", shim));\n});\n```\n\nOpen `http:\u002F\u002Flocalhost:3000\u002Fwidget-preview?payload={\"rows\":[...]}` in a normal browser tab and iterate with ordinary devtools.\n\n**Host fallback** — use a host without the apps surface (or MCP Inspector) and confirm the tool's text content degrades gracefully.\n\n**CSP debugging** — open the iframe's own devtools console. CSP violations are the #1 reason widgets silently fail (blank rectangle, no error in the main console). See `references\u002Fiframe-sandbox.md`.\n\n---\n\n## Reference files\n\n- `references\u002Fiframe-sandbox.md` — CSP\u002Fsandbox constraints, the bundle-inlining pattern, image handling, host theming\n- `references\u002Fwidget-templates.md` — reusable HTML scaffolds for picker \u002F confirm \u002F progress \u002F display\n- `references\u002Fapps-sdk-messages.md` — the `App` class API: widget ↔ host ↔ server messaging, lifecycle & supersession\n- `references\u002Fpayload-budgeting.md` — host tool-result size caps, prune-then-truncate, heavy assets via `callServerTool`\n- `references\u002Fabuse-protection.md` — Anthropic egress CIDRs, tiered rate limiting, `trust proxy`, response caching\n- `references\u002Fdirectory-checklist.md` — pre-flight for connector-directory submission\n","# Build an MCP App (Interactive UI Widgets)\n\nAn MCP app is a standard MCP server that **also serves UI resources** — interactive components rendered inline in the chat surface. Build once, runs in Claude *and* ChatGPT and any other host that implements the apps surface.\n\nThe UI layer is **additive**. Under the hood it's still tools, resources, and the same wire protocol. If you haven't built a plain MCP server before, the `build-mcp-server` skill covers the base layer. This skill adds widgets on top.\n\n> **Testing in Claude:** Add the server as a custom connector in claude.ai (via a Cloudflare tunnel for local dev) — this exercises the real iframe sandbox and `hostContext`. See https:\u002F\u002Fclaude.com\u002Fdocs\u002Fconnectors\u002Fbuilding\u002Ftesting.\n\n## Claude host specifics\n\n| `_meta.ui.*` key | Where | Effect |\n|---|---|---|\n| `resourceUri` | tool | Which `ui:\u002F\u002F` resource the host renders for this tool's results. |\n| `visibility: [\"app\"]` | tool | Hide a widget-only helper tool (e.g. geometry\u002Fimage fetcher called via `callServerTool`) from Claude's tool list. |\n| `prefersBorder: false` | resource | Drop the host's outer card border (mobile). |\n| `csp.{connectDomains, resourceDomains, baseUriDomains}` | resource | Declare external origins; default is block-all. `frameDomains` is currently restricted in Claude. |\n\n- `hostContext.safeAreaInsets: {top, right, bottom, left}` (px) — honor these for notches and the composer overlay.\n- Directory submission requires OAuth or **authless** (`none`) — static bearer is private-deploy only and blocks listing — plus tool `annotations` and 3–5 PNG screenshots; see `references\u002Fdirectory-checklist.md`.\n\n---\n\n## When a widget beats plain text\n\nDon't add UI for its own sake — most tools are fine returning text or JSON. Add a widget when one of these is true:\n\n| Signal | Widget type |\n|---|---|\n| Tool needs structured input Claude can't reliably infer | Form |\n| User must pick from a list Claude can't rank (files, contacts, records) | Picker \u002F table |\n| Destructive or billable action needs explicit confirmation | Confirm dialog |\n| Output is spatial or visual (charts, maps, diffs, previews) | Display widget |\n| Long-running job the user wants to watch | Progress \u002F live status |\n\nIf none apply, skip the widget. Text is faster to build and faster for the user.\n\n---\n\n## Widgets vs Elicitation — route correctly\n\nBefore building a widget, check if **elicitation** covers it. Elicitation is spec-native, zero UI code, works in any compliant host.\n\n| Need | Elicitation | Widget |\n|---|---|---|\n| Confirm yes\u002Fno | ✅ | overkill |\n| Pick from short enum | ✅ | overkill |\n| Fill a flat form (name, email, date) | ✅ | overkill |\n| Pick from a large\u002Fsearchable list | ❌ (no scroll\u002Fsearch) | ✅ |\n| Visual preview before choosing | ❌ | ✅ |\n| Chart \u002F map \u002F diff view | ❌ | ✅ |\n| Live-updating progress | ❌ | ✅ |\n\nIf elicitation covers it, use it. See `..\u002Fbuild-mcp-server\u002Freferences\u002Felicitation.md`.\n\n---\n\n## Architecture: two deployment shapes\n\n### Remote MCP app (most common)\n\nHosted streamable-HTTP server. Widget templates are served as **resources**; tool results reference them. The host fetches the resource, renders it in an iframe sandbox, and brokers messages between the widget and Claude.\n\n```\n┌──────────┐  tools\u002Fcall   ┌────────────┐\n│  Claude  │─────────────> │ MCP server │\n│   host   │\u003C── result ────│  (remote)  │\n│          │  + widget ref │            │\n│          │               │            │\n│          │ resources\u002Fread│            │\n│          │─────────────> │  widget    │\n│ ┌──────┐ │\u003C── template ──│  HTML\u002FJS   │\n│ │iframe│ │               └────────────┘\n│ │widget│ │\n│ └──────┘ │\n└──────────┘\n```\n\n### MCPB-packaged MCP app (local + UI)\n\nSame widget mechanism, but the server runs locally inside an MCPB bundle. Use this when the widget needs to drive a **local** application — e.g., a file picker that browses the actual local disk, a dialog that controls a desktop app.\n\nFor MCPB packaging mechanics, defer to the **`build-mcpb`** skill. Everything below applies to both shapes.\n\n---\n\n## How widgets attach to tools\n\nA widget-enabled tool has **two separate registrations**:\n\n1. **The tool** declares a UI resource via `_meta.ui.resourceUri`. Its handler returns plain text\u002FJSON — NOT the HTML.\n2. **The resource** is registered separately and serves the HTML.\n\nWhen Claude calls the tool, the host sees `_meta.ui.resourceUri`, fetches that resource, renders it in an iframe, and pipes the tool's return value into the iframe via the `ontoolresult` event.\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }\n  from \"@modelcontextprotocol\u002Fext-apps\u002Fserver\";\nimport { z } from \"zod\";\n\nconst server = new McpServer({ name: \"contacts\", version: \"1.0.0\" });\n\n\u002F\u002F 1. The tool — returns DATA, declares which UI to show\nregisterAppTool(server, \"pick_contact\", {\n  description: \"Open an interactive contact picker\",\n  annotations: { title: \"Pick Contact\", readOnlyHint: true },\n  inputSchema: { filter: z.string().optional() },\n  _meta: { ui: { resourceUri: \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\" } },\n}, async ({ filter }) => {\n  const contacts = await db.contacts.search(filter);\n  \u002F\u002F Plain JSON — the widget receives this via ontoolresult\n  return { content: [{ type: \"text\", text: JSON.stringify(contacts) }] };\n});\n\n\u002F\u002F 2. The resource — serves the HTML\nregisterAppResource(\n  server,\n  \"Contact Picker\",\n  \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\",\n  {},\n  async () => ({\n    contents: [{\n      uri: \"ui:\u002F\u002Fwidgets\u002Fcontact-picker.html\",\n      mimeType: RESOURCE_MIME_TYPE,\n      text: pickerHtml,  \u002F\u002F your HTML string\n    }],\n  }),\n);\n```\n\nThe URI scheme `ui:\u002F\u002F` is convention. The mime type MUST be `RESOURCE_MIME_TYPE` (`\"text\u002Fhtml;profile=mcp-app\"`) — this is how the host knows to render it as an interactive iframe, not just display the source.\n\n---\n\n## Widget runtime — the `App` class\n\nInside the iframe, your script talks to the host via the `App` class from `@modelcontextprotocol\u002Fext-apps`. This is a **persistent bidirectional connection** — the widget stays alive as long as the conversation is active, receiving new tool results and sending user actions.\n\n```html\n\u003Cscript type=\"module\">\n  \u002F* ext-apps bundle inlined at build time → globalThis.ExtApps *\u002F\n  \u002F*__EXT_APPS_BUNDLE__*\u002F\n  const { App } = globalThis.ExtApps;\n\n  const app = new App({ name: \"ContactPicker\", version: \"1.0.0\" }, {});\n\n  \u002F\u002F Set handlers BEFORE connecting\n  app.ontoolresult = ({ content }) => {\n    const contacts = JSON.parse(content[0].text);\n    render(contacts);\n  };\n\n  await app.connect();\n\n  \u002F\u002F Later, when the user clicks something:\n  function onPick(contact) {\n    app.sendMessage({\n      role: \"user\",\n      content: [{ type: \"text\", text: `Selected contact: ${contact.id}` }],\n    });\n  }\n\u003C\u002Fscript>\n```\n\nThe `\u002F*__EXT_APPS_BUNDLE__*\u002F` placeholder gets replaced by the server at startup with the contents of `@modelcontextprotocol\u002Fext-apps\u002Fapp-with-deps` — see `references\u002Fiframe-sandbox.md` for why this is necessary and the rewrite snippet. **Do not** `import { App } from \"https:\u002F\u002Fesm.sh\u002F...\"`; the iframe's CSP blocks the transitive dependency fetches and the widget renders blank.\n\n| Method | Direction | Use for |\n|---|---|---|\n| `app.ontoolresult = fn` | Host → widget | Receive the tool's return value |\n| `app.ontoolinput = fn` | Host → widget | Receive the tool's input args (what Claude passed) |\n| `app.sendMessage({...})` | Widget → host | Inject a message into the conversation |\n| `app.updateModelContext({...})` | Widget → host | Update context silently (no visible message) |\n| `app.callServerTool({name, arguments})` | Widget → server | Call another tool on your server |\n| `app.openLink({url})` | Widget → host | Open a URL in a new tab (sandbox blocks `window.open`) |\n| `app.getHostContext()` \u002F `app.onhostcontextchanged` | Host → widget | Theme, host CSS vars, `containerDimensions`, `displayMode`, `deviceCapabilities` |\n| `app.requestDisplayMode({mode})` | Widget → host | Ask for `inline` \u002F `pip` \u002F `fullscreen` |\n| `app.downloadFile({name, mimeType, content})` | Widget → host | Host-mediated download (base64 content) |\n| `new App(info, caps, {autoResize: true})` | — | Iframe height tracks rendered content |\n\n`sendMessage` is the typical \"user picked something, tell Claude\" path. `updateModelContext` is for state that Claude should know about but shouldn't clutter the chat. `openLink` is **required** for any outbound navigation — `window.open` and `\u003Ca target=\"_blank\">` are blocked by the sandbox attribute.\n\n**What widgets cannot do:**\n- Access the host page's DOM, cookies, or storage\n- Make network calls to arbitrary origins (CSP-restricted — route through `callServerTool`)\n- Open popups or navigate directly — use `app.openLink({url})`\n- Load remote images reliably — inline as `data:` URLs server-side\n\nKeep widgets **small and single-purpose**. A picker picks. A chart displays. Don't build a whole sub-app inside the iframe — split it into multiple tools with focused widgets.\n\n---\n\n## Scaffold: minimal picker widget\n\n**Install:**\n\n```bash\nnpm install @modelcontextprotocol\u002Fsdk @modelcontextprotocol\u002Fext-apps zod express\n```\n\n**Server (`src\u002Fserver.ts`):**\n\n```typescript\nimport { McpServer } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002Fmcp.js\";\nimport { StreamableHTTPServerTransport } from \"@modelcontextprotocol\u002Fsdk\u002Fserver\u002FstreamableHttp.js\";\nimport { registerAppTool, registerAppResource, RESOURCE_MIME_TYPE }\n  from \"@modelcontextprotocol\u002Fext-apps\u002Fserver\";\nimport express from \"express\";\nimport { readFileSync } from \"node:fs\";\nimport { createRequire } from \"node:module\";\nimport { z } from \"zod\";\n\nconst require = createRequire(import.meta.url);\nconst server = new McpServer({ name: \"contact-picker\", version: \"1.0.0\" });\n\n\u002F\u002F Inline the ext-apps browser bundle into the widget HTML.\n\u002F\u002F The iframe CSP blocks CDN script fetches — bundling is mandatory.\nconst bundle = readFileSync(\n  require.resolve(\"@modelcontextprotocol\u002Fext-apps\u002Fapp-with-deps\"), \"utf8\",\n).replace(\u002Fexport\\{([^}]+)\\};?\\s*$\u002F, (_, body) =>\n  \"globalThis.ExtApps={\" +\n  body.split(\",\").map((p) => {\n    const [local, exported] = p.split(\" as \").map((s) => s.trim());\n    return `${exported ?? local}:${local}`;\n  }).join(\",\") + \"};\",\n);\nconst pickerHtml = readFileSync(\".\u002Fwidgets\u002Fpicker.html\", \"utf8\")\n  .replace(\"\u002F*__EXT_APPS_BUNDLE__*\u002F\", () => bundle);\n\nregisterAppTool(server, \"pick_contact\", {\n  description: \"Open an interactive contact picker. User selects one contact.\",\n  annotations: { title: \"Pick Contact\", readOnlyHint: true },\n  inputSchema: { filter: z.string().optional().describe(\"Name\u002Femail prefix filter\") },\n  _meta: { ui: { resourceUri: \"ui:\u002F\u002Fwidgets\u002Fpicker.html\" } },\n}, async ({ filter }) => {\n  const contacts = await db.contacts.search(filter ?? \"\");\n  return { content: [{ type: \"text\", text: JSON.stringify(contacts) }] };\n});\n\nregisterAppResource(server, \"Contact Picker\", \"ui:\u002F\u002Fwidgets\u002Fpicker.html\", {},\n  async () => ({\n    contents: [{ uri: \"ui:\u002F\u002Fwidgets\u002Fpicker.html\", mimeType: RESOURCE_MIME_TYPE, text: pickerHtml }],\n  }),\n);\n\nconst app = express();\napp.use(express.json());\napp.post(\"\u002Fmcp\", async (req, res) => {\n  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });\n  res.on(\"close\", () => transport.close());\n  await server.connect(transport);\n  await transport.handleRequest(req, res, req.body);\n});\napp.listen(process.env.PORT ?? 3000);\n```\n\nFor local-only widget apps (driving a desktop app, reading local files), swap the transport to `StdioServerTransport` and package via the `build-mcpb` skill.\n\n**Widget (`widgets\u002Fpicker.html`):**\n\n```html\n\u003C!doctype html>\n\u003Cmeta charset=\"utf-8\" \u002F>\n\u003Cstyle>\n  body { font: 14px system-ui; margin: 0; }\n  ul { list-style: none; padding: 0; margin: 0; max-height: 300px; overflow-y: auto; }\n  li { padding: 10px 14px; cursor: pointer; border-bottom: 1px solid #eee; }\n  li:hover { background: #f5f5f5; }\n  .sub { color: #666; font-size: 12px; }\n\u003C\u002Fstyle>\n\u003Cul id=\"list\">\u003C\u002Ful>\n\u003Cscript type=\"module\">\n\u002F*__EXT_APPS_BUNDLE__*\u002F\nconst { App } = globalThis.ExtApps;\n(async () => {\n  const app = new App({ name: \"ContactPicker\", version: \"1.0.0\" }, {});\n  const ul = document.getElementById(\"list\");\n\n  app.ontoolresult = ({ content }) => {\n    const contacts = JSON.parse(content[0].text);\n    ul.innerHTML = \"\";\n    for (const c of contacts) {\n      const li = document.createElement(\"li\");\n      li.innerHTML = `\u003Cdiv>${c.name}\u003C\u002Fdiv>\u003Cdiv class=\"sub\">${c.email}\u003C\u002Fdiv>`;\n      li.addEventListener(\"click\", () => {\n        app.sendMessage({\n          role: \"user\",\n          content: [{ type: \"text\", text: `Selected contact: ${c.id} (${c.name})` }],\n        });\n      });\n      ul.append(li);\n    }\n  };\n\n  await app.connect();\n})();\n\u003C\u002Fscript>\n```\n\nSee `references\u002Fwidget-templates.md` for more widget shapes.\n\n---\n\n## Design notes that save you a rewrite\n\n**One widget per tool.** Resist the urge to build one mega-widget that does everything. One tool → one focused widget → one clear result shape. Claude reasons about these far better.\n\n**Tool description must mention the widget.** Claude only sees the tool description when deciding what to call. \"Opens an interactive picker\" in the description is what makes Claude reach for it instead of guessing an ID.\n\n**Widgets are optional at runtime.** Hosts that don't support the apps surface simply ignore `_meta.ui` and render the tool's text content normally. Since your tool handler already returns meaningful text\u002FJSON (the widget's data), degradation is automatic — Claude sees the data directly instead of via the widget.\n\n**Don't block on widget results for read-only tools.** A widget that just *displays* data (chart, preview) shouldn't require a user action to complete. Return the display widget *and* a text summary in the same result so Claude can continue reasoning without waiting.\n\n**Layout-fork by item count, not by tool count.** If one use case is \"show one result in detail\" and another is \"show many results side-by-side\", don't make two tools — make one tool that accepts `items[]`, and let the widget pick a layout: `items.length === 1` → detail view, `> 1` → carousel. Keeps the server schema simple and lets Claude decide count naturally.\n\n**Put Claude's reasoning in the payload.** A short `note` field on each item (why Claude picked it) rendered as a callout on the card gives users the reasoning inline with the choice. Mention this field in the tool description so Claude populates it.\n\n**Normalize image shapes server-side.** If your data source returns images with wildly varying aspect ratios, rewrite to a predictable variant (e.g. square-bounded) *before* fetching for the data-URL inline. Then give the widget's image container a fixed `aspect-ratio` + `object-fit: contain` so everything sits centered.\n\n**Follow host theme.** `app.getHostContext()?.theme` (after `connect()`) plus `app.onhostcontextchanged` for live updates. Toggle a `.dark` class on `\u003Chtml>`, keep colors in CSS custom props with a `:root.dark {}` override block, set `color-scheme`. Disable `mix-blend-mode: multiply` in dark — it makes images vanish.\n\n---\n\n## Testing\n\n**Claude Desktop** — current builds still require the `command`\u002F`args` config shape (no native `\"type\": \"http\"`). Wrap with `mcp-remote` and force `http-only` transport so the SSE probe doesn't swallow widget-capability negotiation:\n\n```json\n{\n  \"mcpServers\": {\n    \"my-server\": {\n      \"command\": \"npx\",\n      \"args\": [\"-y\", \"mcp-remote\", \"http:\u002F\u002Flocalhost:3000\u002Fmcp\",\n               \"--allow-http\", \"--transport\", \"http-only\"]\n    }\n  }\n}\n```\n\nDesktop caches UI resources aggressively. After editing widget HTML, **fully quit** (⌘Q \u002F Alt+F4, not window-close) and relaunch to force a cold resource re-fetch.\n\n**Headless JSON-RPC loop** — fast iteration without clicking through Desktop:\n\n```bash\n# test.jsonl — one JSON-RPC message per line\n{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2025-06-18\",\"capabilities\":{},\"clientInfo\":{\"name\":\"t\",\"version\":\"0\"}}}\n{\"jsonrpc\":\"2.0\",\"method\":\"notifications\u002Finitialized\"}\n{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools\u002Flist\"}\n{\"jsonrpc\":\"2.0\",\"id\":3,\"method\":\"tools\u002Fcall\",\"params\":{\"name\":\"your_tool\",\"arguments\":{...}}}\n\n(cat test.jsonl; sleep 10) | npx mcp-remote http:\u002F\u002Flocalhost:3000\u002Fmcp --allow-http\n```\n\nThe `sleep` keeps stdin open long enough to collect all responses. Parse the jsonl output with `jq` or a Python one-liner.\n\n**Widget dev loop** — avoid the ⌘Q-relaunch cycle entirely by serving the inlined widget HTML at a plain GET route with a fake `ExtApps` shim that fires `ontoolresult` from a query param:\n\n```ts\napp.get(\"\u002Fwidget-preview\", (_req, res) => {\n  const shim = `globalThis.ExtApps={applyHostStyleVariables:()=>{},App:class{\n    constructor(){this.h={}} ontoolresult;onhostcontextchanged;\n    async connect(){const p=new URLSearchParams(location.search).get(\"payload\");\n      if(p)this.ontoolresult?.({content:[{type:\"text\",text:p}]});}\n    getHostContext(){return{theme:\"light\"}}\n    sendMessage(m){console.log(\"sendMessage\",m)} updateModelContext(){}\n    callServerTool(){return Promise.resolve({content:[]})} openLink(){} downloadFile(){}\n  }};`;\n  res.type(\"html\").send(widgetHtml.replace(\"\u002F*__EXT_APPS_BUNDLE__*\u002F\", shim));\n});\n```\n\nOpen `http:\u002F\u002Flocalhost:3000\u002Fwidget-preview?payload={\"rows\":[...]}` in a normal browser tab and iterate with ordinary devtools.\n\n**Host fallback** — use a host without the apps surface (or MCP Inspector) and confirm the tool's text content degrades gracefully.\n\n**CSP debugging** — open the iframe's own devtools console. CSP violations are the #1 reason widgets silently fail (blank rectangle, no error in the main console). See `references\u002Fiframe-sandbox.md`.\n\n---\n\n## Reference files\n\n- `references\u002Fiframe-sandbox.md` — CSP\u002Fsandbox constraints, the bundle-inlining pattern, image handling, host theming\n- `references\u002Fwidget-templates.md` — reusable HTML scaffolds for picker \u002F confirm \u002F progress \u002F display\n- `references\u002Fapps-sdk-messages.md` — the `App` class API: widget ↔ host ↔ server messaging, lifecycle & supersession\n- `references\u002Fpayload-budgeting.md` — host tool-result size caps, prune-then-truncate, heavy assets via `callServerTool`\n- `references\u002Fabuse-protection.md` — Anthropic egress CIDRs, tiered rate limiting, `trust proxy`, response caching\n- `references\u002Fdirectory-checklist.md` — pre-flight for connector-directory submission\n",{"name":5,"version":54,"description":7},"0.1.0","main","dceb15d50832e6adf380bedc26dde03d251324b9","plugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app",4865,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official","https:\u002F\u002Fcode.claude.com\u002Fdocs\u002Fen\u002Fplugins","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-11-11 08:12:44",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add anthropics\u002Fclaude-plugins-official --skill build-mcp-app",{"tool":70,"command":71},"bunx","bunx skills add anthropics\u002Fclaude-plugins-official --skill build-mcp-app",{"tool":73,"command":74},"pnpm","pnpm dlx skills add anthropics\u002Fclaude-plugins-official --skill build-mcp-app","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002FSKILL.md",true,[78,84,88,92,96,100],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fabuse-protection.md","REFERENCE","参考文档",2412,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fabuse-protection.md",{"path":85,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fapps-sdk-messages.md",8772,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fapps-sdk-messages.md",{"path":89,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fdirectory-checklist.md",1552,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fdirectory-checklist.md",{"path":93,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fiframe-sandbox.md",5188,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fiframe-sandbox.md",{"path":97,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fpayload-budgeting.md",2175,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fpayload-budgeting.md",{"path":101,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fwidget-templates.md",8924,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-server-dev\u002Fskills\u002Fbuild-mcp-app\u002Freferences\u002Fwidget-templates.md",[105,133,157,182,207,228],{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":109,"sourceHtmlUrl":110,"categories":111,"keywords":113,"publishedAt":49},"01M718BVSPNAK6S5NZCYFDBG6E","skill-creator","Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fskill-creator\u002Fskills\u002Fskill-creator\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fskill-creator\u002Fskills\u002Fskill-creator\u002FSKILL.md",[112],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[114,115,116,117,118,119,35,120,121,122,123,124,125,126,127,128,129,130,131,132],"skill creator","creator","performance","improve","run evals","new","analysis","create","optimize","variance analysis","run","edit","benchmark","existing skill","evals","for","accuracy","scratch","use",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":142,"publishedAt":49},"01M718BSVAWJRFN6MRCZZ0QX4X","session-report","Generate an explorable HTML report of Claude Code session usage (tokens, cache, subagents, skills, expensive prompts) from ~\u002F.claude\u002Fprojects transcripts.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fsession-report\u002Fskills\u002Fsession-report\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000034","行政与办公人员",[143,144,145,146,147,148,149,150,151,152,153,154,155,156],"session","report","session report","projects","usage","generate","tokens","html report","transcripts","prompts","cache","code","html","subagents",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":166,"publishedAt":49},"01M718BPKHVD214FAS1T4E5XCE","receipts","Generate a personal Claude Code usage & impact report (\"receipts\") from this machine's local session transcripts — for justifying Claude Code usage\u002Fspend to a manager, self-review, or \"what have I been using this for\" check-ins. Mines ~\u002F.claude\u002Fprojects locally (no extra API calls beyond one final write-up), cross-references local git history, and writes a markdown report plus a self-contained HTML receipt to your home directory. Use when the user asks for \"receipts\", an \"impact report\", \"usage report\", wants to \"show my Claude Code activity\", \"prove the value of Claude Code\", or runs `\u002Freceipts`.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Freceipts\u002Fskills\u002Freceipts\u002FSKILL.md",[163],{"categoryNo":164,"categoryName":165,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师",[159,146,167,168,169,170,35,154,171,172,173,174,148,175,176,177,178,179,180,181],"show","up","local","impact","api","review","self","references","markdown","directory","write","git","activity","my","manager",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":188,"publishedAt":49},"01M718BJMX0T4691FJQ62GYY5C","project-artifact","Generate and publish a project status artifact — an opinionated, tabbed status page for a project too big for one update (overview & success criteria, the workstream sequence, next steps, plus background, plan, risks & open questions, and decisions\u002FFAQ when they earn a tab) — published with the built-in Artifact tool to a default-private claude.ai page the user can share with teammates. Use when a piece of work spans several workstreams and you want a shareable overview kept current. Each artifact is backed by a small per-project config in the plugin data dir, so refreshing it re-gathers live state, redeploys the same URL, and reports only the delta. For software projects whose workstreams are PRs, also read swe.md (the X.Y PR-numbering convention; pulling PR state with gh\u002Fgit; a per-PR detail block). Needs the built-in Artifact tool (claude.ai login). Not for single-PR changes or public docs.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fproject-artifact\u002Fskills\u002Fproject-artifact\u002FSKILL.md",[],[189,190,191,192,146,193,194,195,196,197,198,35,199,200,201,202,203,204,205,206],"project","artifact","project artifact","project status","re","default","next steps","open","only","SWE","URL","you","reports","publish","work","plan","status page","next",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":49},"01M718BF1TTFP5CM0S5HBW64FJ","skill-development","This skill should be used when the user wants to \"create a skill\", \"add a skill to plugin\", \"write a new skill\", \"improve skill description\", \"organize skill content\", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fplugin-dev\u002Fskills\u002Fskill-development\u002FSKILL.md",[213],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[215,216,217,117,119,218,35,154,121,219,177,220,221,222,223,129,224,225,226,227],"development","skill development","skill to plugin","improve skill","structure","organize","new skill","claude code plugins","add","progressive","best practices","progressive disclosure","plugin",{"skillNo":229,"name":230,"nameZh":6,"description":231,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":232,"categories":233,"keywords":235,"publishedAt":49},"01M718BCARZ2J4PW0X3AJCZ8MZ","plugin-structure","This skill should be used when the user asks to \"create a plugin\", \"scaffold a plugin\", \"understand plugin structure\", \"organize plugin components\", \"set up plugin.json\", \"use ${CLAUDE_PLUGIN_ROOT}\", \"add commands\u002Fagents\u002Fskills\u002Fhooks\", \"configure auto-discovery\", or needs guidance on plugin directory layout, manifest configuration, component organization, file naming conventions, or Claude Code plugin architecture best practices.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fclaude-plugins-official\u002Fblob\u002Fmain\u002Fplugins\u002Fplugin-dev\u002Fskills\u002Fplugin-structure\u002FSKILL.md",[234],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[219,236,227,237,238,239,168,240,241,35,242,154,46,243,121,244,245,246,176,247],"Plugin Structure","SET","plugin architecture","hooks","auto-discovery","auto","configure","architecture","component","layout","organization","commands"]