Generate SDK Locally

MCP Tools

Prerequisites: azure-sdk-mcp server must be running. Without MCP, use npx tsp-client CLI.

Steps

1. Select language — Confirm target language: .NET, Java, JavaScript, Python, Go, or Rust.
2. Verify repo — Ensure the user has a local clone of the correct SDK repo. If not cloned, instruct user to clone it.
3. Identify config file — Determine the path to the TypeSpec configuration file. See config file details.
   • From azure-rest-api-specs repo: use path to tspconfig.yaml.
   • From an SDK language repo: use path to tsp-location.yaml.
4. Verify setup — Run azure-sdk-mcp:azsdk_verify_setup to confirm environment.
5. Generate — Run azure-sdk-mcp:azsdk_package_generate_code with the config file path.
6. Build — Run azure-sdk-mcp:azsdk_package_build_code. If build succeeds, proceed to step 8.
7. Customize — If build fails, or if user requests SDK modifications, run azure-sdk-mcp:azsdk_customized_code_update with the build errors or user request. The tool handles the full workflow internally: it classifies the issue, applies TypeSpec decorators and/or code patches, regenerates the SDK, and builds — all in one call. See customization workflow.
8. Commit checkpoint — Prompt the user to commit generated changes before proceeding. See commit checkpoint details.
9. Validate — Run azure-sdk-mcp:azsdk_package_run_check and azure-sdk-mcp:azsdk_package_run_tests.
10. Metadata — Run azure-sdk-mcp:azsdk_package_update_changelog_content, azure-sdk-mcp:azsdk_package_update_metadata, and azure-sdk-mcp:azsdk_package_update_version. (Note: For .NET data plane, skip this step — metadata, changelog, and version updates are per-commit tasks, not part of the generate/build/test workflow.)
11. Final commit — Prompt the user to commit final changes (changelog, metadata, version). See commit checkpoint details.

SDK repos | Customization workflow | Detailed workflow

Guardrails

• NEVER modify generated SDK code files directly for customizations. Always use azure-sdk-mcp:azsdk_customized_code_update. It handles classification, TypeSpec decorators, code patches, regeneration, and build as a single atomic workflow.
• If azure-sdk-mcp:azsdk_customized_code_update fails or times out, report the error to the user and suggest retrying. Do not attempt to replicate its behavior by editing files manually.
• Only the customization tool understands the correct layering of TypeSpec decorators vs code patches and ensures regenerated code stays consistent.

Examples

• "Generate the SDK locally for my TypeSpec service"
• "Build and test the Python SDK package"
• "Run CI checks for my SDK package"
• "Fix the SDK build errors on this PR"
• "The SDK generation has breaking changes, resolve them"
• "Rename FooClient to BarClient for .NET"
• "Hide the internal polling operation from the Python SDK"
• "Fix .NET analyzer errors AZC0030 and AZC0012"
• "The build is failing because a customization references a renamed property"
• "Create a subclient architecture for the Python SDK"
• "Apply TypeSpec customizations to fix compilation errors"
• "Update the changelog for this SDK package"
• "Update the package version"
• "Update the package metadata and ci.yml"

Troubleshooting

• Run azure-sdk-mcp:azsdk_verify_setup to confirm MCP and tools.
• If build fails with type conflicts, breaking changes, analyzer errors, or customization drift, use azure-sdk-mcp:azsdk_customized_code_update to apply customizations.
• The customization tool uses a two-phase approach: TypeSpec decorators first (Phase A), then code repairs if needed (Phase B).
• If azure-sdk-mcp:azsdk_customized_code_update fails or times out, report the error and retry. Do not manually edit generated SDK code — manual edits will be overwritten on the next regeneration.
• Without MCP, use npx tsp-client CLI.