Add Manifest Sample

Add a new sample to the Template Manifest

This skill explains how to register a new template in the Azure Functions Template Manifest so it appears in the VS Code Azure Functions extension and other consumers.

Who consumes the manifest

Changes to manifest.json are surfaced by multiple downstream consumers, so keep entries accurate and validated:

• Azure Functions VS Code Extension — shows templates (and their categories) in the create-project / create-sample experience.
• Azure Functions CLI (Core Tools) v5 — quickstart command uses the manifest to list and scaffold samples.
• Azure MCP tool — exposes the manifest's templates to MCP clients/agents in Azure Functions Tools.
• Azure skills — Copilot/agent skills that read the manifest to recommend or generate Functions samples (entry point Azure MCP Tool)

Files you will touch

The manifest file is written as canonical json.dumps(indent=2, ensure_ascii=False) output with a trailing newline. Preserve that formatting (2-space indent, no trailing whitespace).

Step 1 — Inspect the source repository first

Never guess what a sample does. Inspect the actual repo at the exact tag you will pin (gitRef) and confirm:

• The folder (folderPath) and tag (gitRef) exist.
• The real trigger/function names.
• Whether it actually uses a binding you plan to mention. For example, only claim "Blob output" if the code really has a Blob output binding — sibling samples in different languages often differ (e.g. C# may use BlobOutput while the TypeScript/Python ports only log the payload).

gh api "repos/<owner>/<repo>/contents/<folderPath>?ref=refs/tags/<tag>" --jq '.[] | "\(.type)\t\(.name)"'

Step 2 — Add the template object

Insert the template object adjacent to its peer entries (same resource value) in the templates array, maintaining priority order within that group. If no peers exist, append to the end of the array. Mirror the existing entry for the same family/resource so the new one is consistent.

Mandatory fields for a new sample

A new template must include all of the following.

Enforced by the schema: id, displayName, shortDescription, longDescription, language, bindingType, resource, iac, priority, categories, repositoryUrl, folderPath, gitRef.

Other fields (whatsIncluded, author, isHighlighted) are optional but recommended where applicable. tags is deprecated — do not add it.

Field rules

• id — kebab-case, unique (matches the schema id pattern). Convention: <resource-or-feature>-<binding>-<language> (e.g. office365-connector-trigger-python). Before adding the entry, search templates for a matching id. If a collision is found, inform the user and suggest an alternative id (for example, append a version suffix or disambiguating term). Never silently overwrite or duplicate an id.
• displayName — "<Friendly Name> (<Lang> + AZD + Bicep)".
• language — must be one of the schema language enum values.
• bindingType — must be one of the schema bindingType enum values.
• resource — must be one of the schema resource enum values. Add a new enum value to manifest.schema.json only if none fits, and reuse it consistently.
• iac — must be one of the schema iac enum values.
• The same enum-extension rule applies to language, bindingType, and iac: add a new enum value in manifest.schema.json only when no existing value fits, then reuse it consistently across related samples. When any enum is extended, bump manifest version with a minor increment.
• repositoryUrl — must satisfy the schema pattern (GitHub HTTPS URL).
• folderPath — path within the repo (. for root).
• gitRef — mandatory for new samples. Always pin a signed release tag, e.g. refs/tags/v1.0.0. Never leave it unset and never point a new sample at a moving branch (refs/heads/main) — that makes the template non-reproducible. Verify the tag exists before committing. Whenever the sample repo ships a new release, ask the user to update gitRef to the new tag (and re-verify the pinned folderPath/contents still match) so the manifest tracks the intended release. If the gitRef tag does not exist in the target repository, do not proceed with adding the template. Inform the user that the tag was not found, provide the exact gh api command used to verify, and ask them to confirm the tag name or create the release first.

The allowed values, patterns, and limits for every field are defined in schemas/manifest.schema.json — read them there rather than relying on a copy. A quick way to print the enums:

cd Functions.Templates\Template-Manifest
@'
import json
p = json.load(open(r"schemas\manifest.schema.json", encoding="utf-8"))["$defs"]["template"]["properties"]
for f in ("language", "bindingType", "resource", "iac"):
    print(f, "->", p[f]["enum"])
'@ | python -

Categories (match existing — shown in VS Code)

categories are displayed/filtered in the VS Code extension, so only use categories that already exist in the manifest unless you have a deliberate reason to introduce a new one. Derive the current set from the manifest instead of hardcoding it:

cd Functions.Templates\Template-Manifest
@'
import json
d = json.load(open("manifest.json", encoding="utf-8"))
print(sorted({c for t in d["templates"] for c in t["categories"]}))
'@ | python -

Most starter samples include starters plus a domain category (e.g. ["starters", "connectors", "event-processing"]). Values are kebab-case.

tags are deprecated

Do not add a tags array to new entries. It is deprecated and not used by consumers. (Older entries may still contain it; leave those as-is unless asked.)

Description pattern

Match the established pattern used across the manifest:

• shortDescription (respect the schema's maxLength): a concise capability summary that ends with deployed via azd for azd-based templates. Pattern: "<Service> <scope> <mechanism>, deployed via azd". Example: "Office 365 Outlook email and calendar connector triggers with Blob output, deployed via azd". If the sample is not azd-based (for example, iac is none or deployment is manual), omit the deployed via azd suffix. End with the real deployment mechanism (for example, deployed via ARM template) or with the capability summary when no deployment mechanism is represented.

• longDescription: start with the imperative Build and deploy …, then explicitly name the trigger(s) and binding(s) the sample demonstrates — e.g. the specific trigger type(s) (ConnectorTrigger, McpToolTrigger, CosmosDBTrigger, …) and any input/output bindings (BlobInput/BlobOutput, etc.). Enumerate (1) … (2) … when there are multiple functions/tools, naming each one. Only list a binding if the sample's code actually uses it (verify per language — siblings often differ). Then name the SDK/extension, give the hosting/auth summary, and end with Deployed with azd. For non-azd samples, omit the Deployed with azd. closing and end with the deployment approach actually used or a neutral capability summary.

• whatsIncluded: a short list of concrete artifacts (functions, bindings, infra, azd config). Keep claims accurate to the real sample.