[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699M92BPNMZ0R2RNG58FPPZ":3,"skill-same:01M699M92BPNMZ0R2RNG58FPPZ":79},{"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":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":61,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":78},"01M699M92BPNMZ0R2RNG58FPPZ","generate-codeful-mcp-tool",null,"Generate a self-contained JavaScript server runtime and registration metadata for an MCP codeful tool. Use when the user asks to create a codeful MCP tool, generate server logic for an MCP tool, write a runTool function, build a Dataverse-backed MCP tool, or pair MCP server logic with an MCP App widget.","microsoft\u002Fpower-platform-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699JVYJFB75D9JM70BN4H0Q",1149,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-apps\u002Fskills\u002Fgenerate-codeful-mcp-tool\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,9,43,44],"generate codeful mcp tool","generate","tool","MCP","pair","when","result","for","app","runtime","self","registration","edit","write","read","Bash","server","create","dataverse","javascript","mcp server","2026-11-10 10:12:30",false,"---\nname: generate-codeful-mcp-tool\nversion: 1.0.0\ndescription: >\n  Generate a self-contained JavaScript server runtime and registration metadata\n  for an MCP codeful tool.\n  Use when the user asks to create a codeful MCP tool, generate server logic for\n  an MCP tool, write a runTool function, build a Dataverse-backed MCP tool, or\n  pair MCP server logic with an MCP App widget.\nauthor: Microsoft Corporation\nargument-hint: \u003Ctool purpose, inputs, and expected result>\nuser-invocable: true\nallowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill\n---\n\n**Triggers:** codeful MCP tool, MCP server tool, generate runTool, MCP tool JavaScript,\nDataverse MCP tool, server logic for MCP App\n\n**Keywords:** mcp apps, codeful tool, runTool, dataApi, Dataverse, server runtime\n\n**Aliases:** \u002Fgenerate-codeful-mcp-tool, \u002Fcodeful-tool\n\n**References:**\n- Host API types: [codeful-tool-host-data-api.d.ts](..\u002F..\u002Freferences\u002Fcodeful-tool-host-data-api.d.ts)\n- Known-good tool: [account-summary.tool.js](..\u002F..\u002Fsamples\u002Faccount-summary.tool.js)\n- Known-good metadata: [account-summary.tool.json](..\u002F..\u002Fsamples\u002Faccount-summary.tool.json)\n- Widget generation: [generate-mcp-app-ui](..\u002Fgenerate-mcp-app-ui\u002FSKILL.md)\n\n---\n\nYou generate a matched pair of files for one MCP tool:\n\n- `\u003Ctool-name>.tool.js`: the complete JavaScript server implementation.\n- `\u003Ctool-name>.tool.json`: declarative registration metadata containing the tool name,\n  description, input schema, output schema, and MCP tool annotations.\n\nThe host imports the JavaScript module and calls:\n\n```javascript\nawait runTool({ toolInput, dataApi });\n```\n\n## Required information\n\nBefore generating, establish:\n\n1. The tool's purpose and kebab-case tool name. Use the purpose to write a concise,\n   model-actionable tool description; ask only when the intended behavior is ambiguous.\n2. Its input fields, types, required fields, and constraints. Accept a JSON Schema, a\n   representative input object, or an exact field description. Never guess the input shape.\n3. The expected result, preferably as a representative output object.\n4. Whether it reads or writes Dataverse, the requested tables in business terms, and\n   whether any write creates, appends, updates, overwrites, or deletes state.\n5. Whether the user also wants an MCP App widget.\n\nAsk only for information that is missing. A sample input\u002Foutput is preferred but not\nmandatory when the user has supplied an equally precise contract.\n\n## Phase 1: Read the runtime and metadata contracts\n\nRead:\n\n```text\n${PLUGIN_ROOT}\u002Freferences\u002Fcodeful-tool-host-data-api.d.ts\n${PLUGIN_ROOT}\u002Fsamples\u002Faccount-summary.tool.js\n${PLUGIN_ROOT}\u002Fsamples\u002Faccount-summary.tool.json\n```\n\nThe generated runtime is plain ESM JavaScript, and the sidecar is plain JSON. Type files\nare generation-time references only and MUST NOT be imported by the output.\n\n## Phase 2: Verify Dataverse schema when needed\n\nSkip this phase when the tool does not use Dataverse.\n\nFor a Dataverse-backed tool:\n\n1. Confirm PAC CLI is authenticated to the intended environment.\n2. Discover candidate tables:\n\n   ```powershell\n   pac model list-tables --search \"table terms\"\n   ```\n\n   `--search` is substring-based. Post-filter its output and accept a table only when its\n   logical name exactly matches the selected result. If multiple tables remain plausible,\n   ask the user to choose.\n3. Create a unique temporary directory outside the final output path and generate types:\n\n   ```powershell\n   pac model genpage generate-types --data-sources \"logical1,logical2\" --output-file \"\u003Ctemp>\u002FRuntimeTypes.ts\"\n   ```\n\n4. Read `RuntimeTypes.ts`. Extract the registered tables, exact readable\u002Fwritable logical\n   columns, lookup shapes, choice names, and raw numeric choice values.\n5. Use ONLY names and values verified in that file. Custom columns are unpredictable; do\n   not derive them from display names.\n\nIf discovery or type generation fails, stop and report the error. Do not fall back to\ninvented tables or columns. Delete the temporary types and directory after validation so\nthe final output contains only the requested `.tool.js`, `.tool.json`, and optional\nwidget files.\n\n## Phase 3: Generate the paired tool artifacts\n\nWrite `\u003Ctool-name>.tool.js` and `\u003Ctool-name>.tool.json` in the user's working directory\nunless they requested another output directory. Both files MUST use the same basename,\nwhich MUST equal the confirmed kebab-case tool name.\n\nThe JavaScript file MUST:\n\n- Export exactly one MCP entry point named `runTool`, preferably:\n\n  ```javascript\n  export async function runTool({ toolInput, dataApi }) {\n    \u002F\u002F complete implementation\n  }\n  ```\n\n- Be self-contained JavaScript with no runtime imports, packages, network calls,\n  filesystem access, environment-variable access, or generated-type dependency.\n- Validate all externally supplied `toolInput` before using it. Apply bounds to counts and\n  escape values interpolated into OData filters.\n- Use singular Dataverse entity logical names. Use exact logical column names in `select`,\n  `filter`, `orderBy`, and row objects.\n- Read choice and lookup labels from\n  `\"\u003Ccolumn>@OData.Community.Display.V1.FormattedValue\"`.\n- Access query rows through `page.rows`. Follow `page.loadMoreRows()` only while\n  `page.hasMoreRows` is true and the function exists.\n- Set lookups through the verified `_\u003Cfield>_value` shape from `RuntimeTypes.ts`; never\n  emit raw Web API `@odata.bind` keys.\n- Let `dataApi` failures throw. Catch only when adding useful context, and rethrow with the\n  original error as the cause. Never return a success-shaped fallback after a failed read\n  or write.\n- Contain no placeholders, TODOs, ellipses, test credentials, or real environment IDs.\n- Return JSON-serializable values only. Never return `loadMoreRows`, functions, class\n  instances, or cyclic objects.\n- Emit telemetry only when the user explicitly asks for it, and never include tool inputs,\n  row contents, identifiers, or other user data in telemetry properties.\n\nThe JSON sidecar MUST be valid JSON with exactly these top-level fields:\n\n```json\n{\n  \"name\": \"account-summary\",\n  \"description\": \"Search accounts and return revenue and status summaries.\",\n  \"annotations\": {\n    \"readOnlyHint\": true,\n    \"destructiveHint\": false,\n    \"idempotentHint\": true,\n    \"openWorldHint\": false\n  },\n  \"inputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {}\n  },\n  \"outputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {}\n  }\n}\n```\n\n- `name`: exactly the confirmed tool name and the shared file basename.\n- `description`: concise, model-actionable guidance explaining what the tool does and when\n  to call it. Do not copy the user's prompt verbatim or include implementation details.\n- `annotations`: MCP\n  [`ToolAnnotations`](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-06-18\u002Fschema#toolannotations)\n  describing the tool's behavior. Always emit all four boolean hints:\n  - `readOnlyHint`: `true` only when the tool cannot modify Dataverse or any other state.\n  - `destructiveHint`: `true` when the tool may delete, overwrite, or otherwise cause a\n    destructive update. Set it to `false` for read-only tools and non-destructive creates\n    or additive writes.\n  - `idempotentHint`: `true` when repeated calls with the same valid input have no\n    additional effect. Reads, deterministic calculations, and updates that set the same\n    values are idempotent; creates and append-style operations are not.\n  - `openWorldHint`: always `false` because the codeful runtime cannot access arbitrary\n    external systems.\n  Infer these values from the generated implementation and requested behavior. If the\n  write semantics are genuinely ambiguous, ask before generating rather than guessing.\n  Treat annotations as advisory metadata, not as a substitute for runtime validation or\n  authorization.\n- `inputSchema`: the complete JSON Schema for `toolInput`. Use an object root, list every\n  accepted field under `properties`, identify required fields with `required`, encode\n  runtime constraints such as bounds, formats, enums, and array item shapes, and set\n  `additionalProperties: false` unless the user explicitly requires extensible input.\n- `outputSchema`: the JSON Schema for the model-visible `structuredContent` business\n  payload. For a plain-object return, describe the complete returned object because the\n  host promotes it to `structuredContent`. For an envelope return, describe only its\n  `structuredContent` property. Never include `content`, authored `meta`, or runtime\n  `_meta` in `outputSchema`.\n\nUse standard JSON Schema keywords only. Do not include credentials, environment\nidentifiers, Dataverse discovery artifacts, host configuration, JavaScript expressions,\ncomments, or placeholders in the sidecar.\n\n## Result-channel contract\n\nChoose the smallest correct result shape.\n\n### Simple structured result\n\nReturn a plain object when all useful output belongs in model-visible structured data:\n\n```javascript\nreturn { records, totalCount: records.length };\n```\n\nThe host promotes that object to MCP `structuredContent`.\n\n### Partitioned MCP result\n\nReturn an envelope when the channels have different audiences:\n\n```javascript\nreturn {\n  content: `Found ${records.length} records.`,\n  structuredContent: { records },\n  meta: { preferredView: \"table\" },\n};\n```\n\n- `content`: model-visible conversational text, either a string or text content blocks.\n- `structuredContent`: model-visible machine-readable object.\n- `meta`: widget-only object. The host maps it to MCP `_meta`; widgets read `result._meta`.\n\nThe names `content`, `structuredContent`, and `meta` are reserved envelope keys. If a\nbusiness payload naturally has any of those keys, wrap the whole payload explicitly:\n\n```javascript\nreturn { structuredContent: businessPayload };\n```\n\nDo not mix envelope keys with unrelated top-level business fields.\n\n## Phase 4: Validate\n\nBefore reporting completion:\n\n1. Confirm exactly one final `.tool.js` and one matching `.tool.json` were created for\n   this skill.\n2. Import the file as an ESM data URL with Node.js and assert that `runTool` is a function.\n   Importing MUST NOT execute data access or other top-level side effects.\n3. Parse the sidecar with `JSON.parse`. Confirm it has exactly `name`, `description`,\n   `annotations`, `inputSchema`, and `outputSchema`; the name matches both filenames;\n   all four annotation hints are booleans, `openWorldHint` is `false`, the other hints\n   match the implementation's actual behavior, both schemas have object roots, and every\n   input constraint enforced by the runtime is represented in `inputSchema`.\n4. Grep the output for imports, `require`, placeholders, guessed columns, and unsupported\n   host access.\n5. When representative input\u002Foutput was supplied, invoke `runTool` with an in-memory mock\n   `dataApi` from an inline Node script. Do not create a persistent test file.\n6. Confirm the returned value matches the requested result contract, contains no\n   functions or non-serializable values, and its structured payload conforms to\n   `outputSchema`. Confirm the representative input conforms to `inputSchema`.\n7. Delete all temporary schema artifacts.\n\n## Optional MCP App handoff\n\nWhen the user asks for a widget:\n\n1. Finish and validate the paired `.tool.js` and `.tool.json` first.\n2. Build a representative result sample:\n   - Plain tool return -> treat it as `structuredContent`.\n   - Envelope return -> pass `content`, `structuredContent`, and `_meta` (renamed from the\n     authored `meta` field).\n3. Invoke `generate-mcp-app-ui` with the visual requirements, tool name, input sample, and\n   representative full result. Forward an explicit CDN policy from the user's request.\n   If none was supplied, let the UI skill ask its required CDN-policy question; do not\n   assume public URLs are allowed.\n4. Keep the outputs separate: one `.tool.js`, one `.tool.json`, and one single-file\n   `.html` using the selected CDN policy.\n\n## Refinement\n\nWhen editing an existing codeful tool, read both paired files and change only the\nrequested behavior. Keep runtime validation and metadata schemas synchronized. Re-run\nschema verification if the edit introduces a table, column, lookup, or choice value not\nalready verified for the file.\n\n## Completion response\n\nState both generated tool file paths and summarize the description, tool annotations,\ninput contract, and structured result contract. If a widget was requested, also state the\nHTML path and which result channels it consumes.\n","**Triggers:** codeful MCP tool, MCP server tool, generate runTool, MCP tool JavaScript,\nDataverse MCP tool, server logic for MCP App\n\n**Keywords:** mcp apps, codeful tool, runTool, dataApi, Dataverse, server runtime\n\n**Aliases:** \u002Fgenerate-codeful-mcp-tool, \u002Fcodeful-tool\n\n**References:**\n- Host API types: [codeful-tool-host-data-api.d.ts](..\u002F..\u002Freferences\u002Fcodeful-tool-host-data-api.d.ts)\n- Known-good tool: [account-summary.tool.js](..\u002F..\u002Fsamples\u002Faccount-summary.tool.js)\n- Known-good metadata: [account-summary.tool.json](..\u002F..\u002Fsamples\u002Faccount-summary.tool.json)\n- Widget generation: [generate-mcp-app-ui](..\u002Fgenerate-mcp-app-ui\u002FSKILL.md)\n\n---\n\nYou generate a matched pair of files for one MCP tool:\n\n- `\u003Ctool-name>.tool.js`: the complete JavaScript server implementation.\n- `\u003Ctool-name>.tool.json`: declarative registration metadata containing the tool name,\n  description, input schema, output schema, and MCP tool annotations.\n\nThe host imports the JavaScript module and calls:\n\n```javascript\nawait runTool({ toolInput, dataApi });\n```\n\n## Required information\n\nBefore generating, establish:\n\n1. The tool's purpose and kebab-case tool name. Use the purpose to write a concise,\n   model-actionable tool description; ask only when the intended behavior is ambiguous.\n2. Its input fields, types, required fields, and constraints. Accept a JSON Schema, a\n   representative input object, or an exact field description. Never guess the input shape.\n3. The expected result, preferably as a representative output object.\n4. Whether it reads or writes Dataverse, the requested tables in business terms, and\n   whether any write creates, appends, updates, overwrites, or deletes state.\n5. Whether the user also wants an MCP App widget.\n\nAsk only for information that is missing. A sample input\u002Foutput is preferred but not\nmandatory when the user has supplied an equally precise contract.\n\n## Phase 1: Read the runtime and metadata contracts\n\nRead:\n\n```text\n${PLUGIN_ROOT}\u002Freferences\u002Fcodeful-tool-host-data-api.d.ts\n${PLUGIN_ROOT}\u002Fsamples\u002Faccount-summary.tool.js\n${PLUGIN_ROOT}\u002Fsamples\u002Faccount-summary.tool.json\n```\n\nThe generated runtime is plain ESM JavaScript, and the sidecar is plain JSON. Type files\nare generation-time references only and MUST NOT be imported by the output.\n\n## Phase 2: Verify Dataverse schema when needed\n\nSkip this phase when the tool does not use Dataverse.\n\nFor a Dataverse-backed tool:\n\n1. Confirm PAC CLI is authenticated to the intended environment.\n2. Discover candidate tables:\n\n   ```powershell\n   pac model list-tables --search \"table terms\"\n   ```\n\n   `--search` is substring-based. Post-filter its output and accept a table only when its\n   logical name exactly matches the selected result. If multiple tables remain plausible,\n   ask the user to choose.\n3. Create a unique temporary directory outside the final output path and generate types:\n\n   ```powershell\n   pac model genpage generate-types --data-sources \"logical1,logical2\" --output-file \"\u003Ctemp>\u002FRuntimeTypes.ts\"\n   ```\n\n4. Read `RuntimeTypes.ts`. Extract the registered tables, exact readable\u002Fwritable logical\n   columns, lookup shapes, choice names, and raw numeric choice values.\n5. Use ONLY names and values verified in that file. Custom columns are unpredictable; do\n   not derive them from display names.\n\nIf discovery or type generation fails, stop and report the error. Do not fall back to\ninvented tables or columns. Delete the temporary types and directory after validation so\nthe final output contains only the requested `.tool.js`, `.tool.json`, and optional\nwidget files.\n\n## Phase 3: Generate the paired tool artifacts\n\nWrite `\u003Ctool-name>.tool.js` and `\u003Ctool-name>.tool.json` in the user's working directory\nunless they requested another output directory. Both files MUST use the same basename,\nwhich MUST equal the confirmed kebab-case tool name.\n\nThe JavaScript file MUST:\n\n- Export exactly one MCP entry point named `runTool`, preferably:\n\n  ```javascript\n  export async function runTool({ toolInput, dataApi }) {\n    \u002F\u002F complete implementation\n  }\n  ```\n\n- Be self-contained JavaScript with no runtime imports, packages, network calls,\n  filesystem access, environment-variable access, or generated-type dependency.\n- Validate all externally supplied `toolInput` before using it. Apply bounds to counts and\n  escape values interpolated into OData filters.\n- Use singular Dataverse entity logical names. Use exact logical column names in `select`,\n  `filter`, `orderBy`, and row objects.\n- Read choice and lookup labels from\n  `\"\u003Ccolumn>@OData.Community.Display.V1.FormattedValue\"`.\n- Access query rows through `page.rows`. Follow `page.loadMoreRows()` only while\n  `page.hasMoreRows` is true and the function exists.\n- Set lookups through the verified `_\u003Cfield>_value` shape from `RuntimeTypes.ts`; never\n  emit raw Web API `@odata.bind` keys.\n- Let `dataApi` failures throw. Catch only when adding useful context, and rethrow with the\n  original error as the cause. Never return a success-shaped fallback after a failed read\n  or write.\n- Contain no placeholders, TODOs, ellipses, test credentials, or real environment IDs.\n- Return JSON-serializable values only. Never return `loadMoreRows`, functions, class\n  instances, or cyclic objects.\n- Emit telemetry only when the user explicitly asks for it, and never include tool inputs,\n  row contents, identifiers, or other user data in telemetry properties.\n\nThe JSON sidecar MUST be valid JSON with exactly these top-level fields:\n\n```json\n{\n  \"name\": \"account-summary\",\n  \"description\": \"Search accounts and return revenue and status summaries.\",\n  \"annotations\": {\n    \"readOnlyHint\": true,\n    \"destructiveHint\": false,\n    \"idempotentHint\": true,\n    \"openWorldHint\": false\n  },\n  \"inputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {}\n  },\n  \"outputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {}\n  }\n}\n```\n\n- `name`: exactly the confirmed tool name and the shared file basename.\n- `description`: concise, model-actionable guidance explaining what the tool does and when\n  to call it. Do not copy the user's prompt verbatim or include implementation details.\n- `annotations`: MCP\n  [`ToolAnnotations`](https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002F2025-06-18\u002Fschema#toolannotations)\n  describing the tool's behavior. Always emit all four boolean hints:\n  - `readOnlyHint`: `true` only when the tool cannot modify Dataverse or any other state.\n  - `destructiveHint`: `true` when the tool may delete, overwrite, or otherwise cause a\n    destructive update. Set it to `false` for read-only tools and non-destructive creates\n    or additive writes.\n  - `idempotentHint`: `true` when repeated calls with the same valid input have no\n    additional effect. Reads, deterministic calculations, and updates that set the same\n    values are idempotent; creates and append-style operations are not.\n  - `openWorldHint`: always `false` because the codeful runtime cannot access arbitrary\n    external systems.\n  Infer these values from the generated implementation and requested behavior. If the\n  write semantics are genuinely ambiguous, ask before generating rather than guessing.\n  Treat annotations as advisory metadata, not as a substitute for runtime validation or\n  authorization.\n- `inputSchema`: the complete JSON Schema for `toolInput`. Use an object root, list every\n  accepted field under `properties`, identify required fields with `required`, encode\n  runtime constraints such as bounds, formats, enums, and array item shapes, and set\n  `additionalProperties: false` unless the user explicitly requires extensible input.\n- `outputSchema`: the JSON Schema for the model-visible `structuredContent` business\n  payload. For a plain-object return, describe the complete returned object because the\n  host promotes it to `structuredContent`. For an envelope return, describe only its\n  `structuredContent` property. Never include `content`, authored `meta`, or runtime\n  `_meta` in `outputSchema`.\n\nUse standard JSON Schema keywords only. Do not include credentials, environment\nidentifiers, Dataverse discovery artifacts, host configuration, JavaScript expressions,\ncomments, or placeholders in the sidecar.\n\n## Result-channel contract\n\nChoose the smallest correct result shape.\n\n### Simple structured result\n\nReturn a plain object when all useful output belongs in model-visible structured data:\n\n```javascript\nreturn { records, totalCount: records.length };\n```\n\nThe host promotes that object to MCP `structuredContent`.\n\n### Partitioned MCP result\n\nReturn an envelope when the channels have different audiences:\n\n```javascript\nreturn {\n  content: `Found ${records.length} records.`,\n  structuredContent: { records },\n  meta: { preferredView: \"table\" },\n};\n```\n\n- `content`: model-visible conversational text, either a string or text content blocks.\n- `structuredContent`: model-visible machine-readable object.\n- `meta`: widget-only object. The host maps it to MCP `_meta`; widgets read `result._meta`.\n\nThe names `content`, `structuredContent`, and `meta` are reserved envelope keys. If a\nbusiness payload naturally has any of those keys, wrap the whole payload explicitly:\n\n```javascript\nreturn { structuredContent: businessPayload };\n```\n\nDo not mix envelope keys with unrelated top-level business fields.\n\n## Phase 4: Validate\n\nBefore reporting completion:\n\n1. Confirm exactly one final `.tool.js` and one matching `.tool.json` were created for\n   this skill.\n2. Import the file as an ESM data URL with Node.js and assert that `runTool` is a function.\n   Importing MUST NOT execute data access or other top-level side effects.\n3. Parse the sidecar with `JSON.parse`. Confirm it has exactly `name`, `description`,\n   `annotations`, `inputSchema`, and `outputSchema`; the name matches both filenames;\n   all four annotation hints are booleans, `openWorldHint` is `false`, the other hints\n   match the implementation's actual behavior, both schemas have object roots, and every\n   input constraint enforced by the runtime is represented in `inputSchema`.\n4. Grep the output for imports, `require`, placeholders, guessed columns, and unsupported\n   host access.\n5. When representative input\u002Foutput was supplied, invoke `runTool` with an in-memory mock\n   `dataApi` from an inline Node script. Do not create a persistent test file.\n6. Confirm the returned value matches the requested result contract, contains no\n   functions or non-serializable values, and its structured payload conforms to\n   `outputSchema`. Confirm the representative input conforms to `inputSchema`.\n7. Delete all temporary schema artifacts.\n\n## Optional MCP App handoff\n\nWhen the user asks for a widget:\n\n1. Finish and validate the paired `.tool.js` and `.tool.json` first.\n2. Build a representative result sample:\n   - Plain tool return -> treat it as `structuredContent`.\n   - Envelope return -> pass `content`, `structuredContent`, and `_meta` (renamed from the\n     authored `meta` field).\n3. Invoke `generate-mcp-app-ui` with the visual requirements, tool name, input sample, and\n   representative full result. Forward an explicit CDN policy from the user's request.\n   If none was supplied, let the UI skill ask its required CDN-policy question; do not\n   assume public URLs are allowed.\n4. Keep the outputs separate: one `.tool.js`, one `.tool.json`, and one single-file\n   `.html` using the selected CDN policy.\n\n## Refinement\n\nWhen editing an existing codeful tool, read both paired files and change only the\nrequested behavior. Keep runtime validation and metadata schemas synchronized. Re-run\nschema verification if the edit introduces a table, column, lookup, or choice value not\nalready verified for the file.\n\n## Completion response\n\nState both generated tool file paths and summarize the description, tool annotations,\ninput contract, and structured result contract. If a widget was requested, also state the\nHTML path and which result channels it consumes.\n",{"name":5,"author":50,"version":51,"description":52,"allowed-tools":53,"argument-hint":54,"user-invocable":55},"Microsoft Corporation","1.0.0","Generate a self-contained JavaScript server runtime and registration metadata for an MCP codeful tool. Use when the user asks to create a codeful MCP tool, generate server logic for an MCP tool, write a runTool function, build a Dataverse-backed MCP tool, or pair MCP server logic with an MCP App widget.\n","Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill","\u003Ctool purpose, inputs, and expected result>",true,"main","0a55a88fa2855404029d1e5450faf92878baf763","plugins\u002Fmcp-apps\u002Fskills\u002Fgenerate-codeful-mcp-tool",232,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills","https:\u002F\u002Fmicrosoft.github.io\u002Fpower-platform-skills\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 21:46:39",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":55},[68,71,74],{"tool":69,"command":70},"npx","npx skills add microsoft\u002Fpower-platform-skills --skill generate-codeful-mcp-tool",{"tool":72,"command":73},"bunx","bunx skills add microsoft\u002Fpower-platform-skills --skill generate-codeful-mcp-tool",{"tool":75,"command":76},"pnpm","pnpm dlx skills add microsoft\u002Fpower-platform-skills --skill generate-codeful-mcp-tool","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fmcp-apps\u002Fskills\u002Fgenerate-codeful-mcp-tool\u002FSKILL.md",[],[80,99,121,139,153,163],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":45},"01M699WVHX0XN59EPBTTPEKYPG","setup","Use when Process Intelligence needs building, explicit cloud\u002Faccount\u002Fenvironment configuration, sign-in, connection diagnostics, or recovery from an authentication error.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fsetup\u002FSKILL.md",[],[82,38,29,87,88,89,90,91,92,93,94,95,96,97,98,39],"connection","error","sign","intelligence","configuration","use","process","diagnostics","environment","authentication","cloud","recovery",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":110,"publishedAt":45},"01M699WSR9EX55YY1WD9J22FEG","report-issue","Use when the user wants a Process Intelligence bug-report draft or support summary for a failed operation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Freport-issue\u002FSKILL.md",[105],{"categoryNo":106,"categoryName":107,"taxonomyType":108,"taxonomyTypeDesc":109},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[111,112,113,114,115,93,92,116,117,90,118,119,31,29,120],"report issue","report","issue","support","user","bug","summary","draft","operation","bug-report",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":127,"publishedAt":45},"01M699WR26YQ9Q21KE6MJF5B2G","investigate-process","Use when a broad Process Mining business question, observed pattern or competing explanation needs investigation across analytical perspectives.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Finvestigate-process\u002FSKILL.md",[],[93,128,129,130,29,131,132,133,134,38,135,92,136,137,138],"investigate","investigate process","mining","process mining","investigation","perspectives","question","business","pattern","across","analytical",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":145,"publishedAt":45},"01M699WP9SDG5ZR12P8VYNXKTN","derive-metric","Use when a requested measure is missing, a saved custom metric needs reuse, or an ephemeral formula or derived scalar is needed.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fderive-metric\u002FSKILL.md",[],[146,147,38,92,148,149,150,151,152,29],"metric","derive metric","formula","missing","reuse","saved","custom",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":45},"01M699WMG5R8P6SMTDAS1TKF9E","compare-cohorts","Use when comparing process cohorts, departments, periods or before-and-after results under matched definitions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fcompare-cohorts\u002FSKILL.md",[],[160,161,29,92,93,162,38],"compare","compare cohorts","results",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":45},"01M699WJWNVTMP9XK3NCJHV14D","analyze-variants","Use when investigating common or slow variants, repeated work, unusual paths, or a specific Process Mining case.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fpower-platform-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fprocess-intelligence\u002Fskills\u002Fanalyze-variants\u002FSKILL.md",[],[170,171,172,131,29,130,173,174,92,93,38,175,176],"analyze","variants","analyze variants","case","paths","work","common"]