Context
Manvir Kaur (@manvkaur)'s PR #1949 replaced ~9,000 lines of hardcoded Azure Functions templates with dynamic MCP tool calls (functions_template_get), with a 3-tier fallback (CDN manifest → GitHub source → known-good Azure-Samples repos). This dramatically reduced context size and maintenance burden.
App Service should adopt the same pattern.
Scope
The App Service templates introduced in #1609 / PR #1635 currently hard-code:
- 21 files under
plugin/skills/azure-prepare/references/services/app-service/templates/
- ~1,995 lines of code (split across web-app.md, web-api.md, selection.md, composition.md, and recipe
source/{python,nodejs,dotnet}.md files for auth/cosmos/redis/sql)
These could be replaced with an analogous app_service_template_get (or similar) MCP tool that fetches templates dynamically from Azure-Samples repos.
Proposed approach
- Source of truth — identify or create AZD templates in Azure-Samples for each base template (web-app, web-api) × language (Python/Node.js/.NET) × recipe (auth/cosmos/redis/sql)
- MCP tool — extend the Azure MCP server with
app_service_template_get mirroring functions_template_get semantics (language, template, infrastructure, with functionFiles[]/projectFiles[] output arrays)
- Fallback chain — same 3-tier pattern: CDN manifest → GitHub source → known-good repos
- Skill refactor — delete the hardcoded
source/{lang}.md files; keep the orchestration files (composition.md, selection.md) with MCP tool guidance like Functions does
- Eval coverage — add cross-language eval summaries proving templates work end-to-end
Why this isn't blocking PR #1635
PR #1635 ships proven, manually-curated templates that work today. The MCP tool approach requires:
- New MCP server endpoint
- New AZD templates published to Azure-Samples
- Awesome-AZD submissions for discoverability
These prerequisites take time. We don't want to delay shipping App Service Develop equity for an optimization that depends on cross-team work. Ship #1635 first, then layer this enhancement on top.
Reference
Context
Manvir Kaur (@manvkaur)'s PR #1949 replaced ~9,000 lines of hardcoded Azure Functions templates with dynamic MCP tool calls (
functions_template_get), with a 3-tier fallback (CDN manifest → GitHub source → known-good Azure-Samples repos). This dramatically reduced context size and maintenance burden.App Service should adopt the same pattern.
Scope
The App Service templates introduced in #1609 / PR #1635 currently hard-code:
plugin/skills/azure-prepare/references/services/app-service/templates/source/{python,nodejs,dotnet}.mdfiles for auth/cosmos/redis/sql)These could be replaced with an analogous
app_service_template_get(or similar) MCP tool that fetches templates dynamically from Azure-Samples repos.Proposed approach
app_service_template_getmirroringfunctions_template_getsemantics (language,template,infrastructure, withfunctionFiles[]/projectFiles[]output arrays)source/{lang}.mdfiles; keep the orchestration files (composition.md, selection.md) with MCP tool guidance like Functions doesWhy this isn't blocking PR #1635
PR #1635 ships proven, manually-curated templates that work today. The MCP tool approach requires:
These prerequisites take time. We don't want to delay shipping App Service Develop equity for an optimization that depends on cross-team work. Ship #1635 first, then layer this enhancement on top.
Reference
plugin/skills/azure-prepare/references/services/functions/templates/recipes/composition.md