|
1 | 1 | # Azure PowerShell Codegen MCP Server |
2 | 2 |
|
3 | | -A Model Context Protocol (MCP) server that provides tools for generating and managing Azure PowerShell modules using AutoRest. This server helps automate common tasks in the Azure PowerShell code generation process, including handling polymorphism, model directives, and code generation. |
| 3 | +A Model Context Protocol (MCP) server that provides tools for generating and managing Azure PowerShell modules using AutoRest. It now also orchestrates help‑driven example generation, CRUD test scaffolding, and an opinionated partner workflow to keep outputs deterministic and consistent. |
4 | 4 |
|
5 | 5 | ## Overview |
6 | 6 |
|
7 | 7 | This MCP server is designed to work with Azure PowerShell module development workflows. It provides specialized tools for: |
8 | 8 |
|
9 | | -- **AutoRest Code Generation**: Generate PowerShell modules from OpenAPI specifications |
| 9 | +- **Module Scaffolding**: Interactive selection of service → provider → API version and creation of the `<ModuleName>.Autorest` structure |
| 10 | +- **AutoRest Code Generation**: Generate PowerShell modules from OpenAPI specifications (reset/generate/build sequence) |
| 11 | +- **Example Generation**: Create example scripts from swagger example JSON while filtering strictly to parameters documented in help markdown |
| 12 | +- **Test Generation**: Produce per‑resource CRUD test files (idempotent, includes negative test) using the same help‑driven parameter filtering |
| 13 | +- **Help‑Driven Parameter Filtering**: Only parameters present in the generated help (`/src/<Module>/help/*.md`) are allowed in examples/tests |
10 | 14 | - **Model Management**: Handle model directives like `no-inline` and `model-cmdlet` |
11 | | -- **Polymorphism Support**: Automatically detect and configure polymorphic types |
12 | | -- **YAML Configuration**: Parse and manipulate AutoRest configuration files |
| 15 | +- **Polymorphism Support**: Automatically detect and configure parent/child discriminator relationships |
| 16 | +- **YAML Configuration Utilities**: Parse and manipulate AutoRest configuration blocks |
| 17 | +- **Partner Workflow Prompt**: A single prompt that encodes the end‑to‑end deterministic workflow |
13 | 18 |
|
14 | 19 | ## Features |
15 | 20 |
|
16 | 21 | ### Available Tools |
17 | 22 |
|
18 | | -1. **generate-autorest** |
19 | | - - Generates PowerShell code using AutoRest |
20 | | - - Parameters: `workingDirectory` (absolute path to README.md) |
21 | | - |
22 | | -2. **no-inline** |
23 | | - - Converts flattened models to non-inline parameters |
24 | | - - Parameters: `modelNames` (array of model names to make non-inline) |
25 | | - - Useful for complex nested models that shouldn't be flattened |
26 | | - |
27 | | -3. **model-cmdlet** |
28 | | - - Creates `New-` cmdlets for specified models |
29 | | - - Parameters: `modelNames` (array of model names) |
30 | | - - Generates cmdlets with naming pattern: `New-Az{SubjectPrefix}{ModelName}Object` |
31 | | - |
32 | | -4. **polymorphism** |
33 | | - - Handles polymorphic type detection and configuration |
34 | | - - Parameters: `workingDirectory` (absolute path to README.md) |
35 | | - - Automatically identifies parent-child type relationships |
| 23 | +1. **setup-module-structure** |
| 24 | + - Interactive service → provider → API version selection and module name capture |
| 25 | + - Scaffolds `src/<Module>/<Module>.Autorest/` plus initial `README.md` |
| 26 | + - Output placeholder `{0}` = module name |
| 27 | + |
| 28 | +2. **generate-autorest** |
| 29 | + - Executes Autorest reset, generate, and PowerShell build steps within the given working directory |
| 30 | + - Parameters: `workingDirectory` (absolute path to the Autorest folder containing README.md) |
| 31 | + - Output placeholder `{0}` = working directory |
| 32 | + |
| 33 | +3. **create-example** |
| 34 | + - Downloads swagger example JSON, filters parameters to those documented in help markdown (`/src/<Module>/help/<Cmdlet>.md`), and writes example scripts under `examples/` |
| 35 | + - Parameters: `workingDirectory` |
| 36 | + - Output placeholders: `{0}` = harvested specs path, `{1}` = examples dir, `{2}` = reference ideal example dirs |
| 37 | + |
| 38 | +4. **create-test** |
| 39 | + - Generates new `<ResourceName>.Crud.Tests.ps1` files (does not modify stubs) with Create/Get/List/Update/Delete/Negative blocks, using help‑filtered parameters |
| 40 | + - Parameters: `workingDirectory` |
| 41 | + - Output placeholders: `{0}` = harvested specs path, `{1}` = test dir, `{2}` = reference ideal test dirs |
| 42 | + |
| 43 | +5. **polymorphism** |
| 44 | + - Detects discriminator parents and child model names to aid directive insertion |
| 45 | + - Parameters: `workingDirectory` |
| 46 | + - Output placeholders: `{0}` = parents, `{1}` = children, `{2}` = working directory |
| 47 | + |
| 48 | +6. **no-inline** |
| 49 | + - Lists models to be marked `no-inline` (caller inserts directive into README Autorest YAML) |
| 50 | + - Parameters: `modelNames` (array) |
| 51 | + - Output `{0}` = comma-separated model list |
| 52 | + |
| 53 | +7. **model-cmdlet** |
| 54 | + - Lists models for which `New-` object construction cmdlets should be added via directives |
| 55 | + - Parameters: `modelNames` (array) |
| 56 | + - Output `{0}` = comma-separated model list |
36 | 57 |
|
37 | 58 | ### Available Prompts |
38 | 59 |
|
39 | | -- **create-greeting**: Generate customized greeting messages (example prompt) |
| 60 | +- **partner-module-workflow**: Canonical end‑to‑end instruction set (module structure → generation → examples → tests → regeneration) |
| 61 | +- **create-greeting**: Sample/demo greeting prompt |
40 | 62 |
|
41 | 63 | ## Installation |
42 | 64 |
|
|
0 commit comments