BranchDeploy

Withdraws a release note from the public feed. If the note was published, customers stop seeing it immediately, including anyone who has linked to it directly. Also removes drafts that are no longer wanted. The note itself is kept in BranchDeploy, so the wording is not lost and it can be published again later from the account app.

archive_release_note

Returns the current status of one deployment by its ID, including the Azure Pipelines outcome, so it shows whether a deployment has finished. status moves from queued to running, then ends as succeeded, partially_succeeded, failed, or cancelled. It is outcome_unknown when Azure DevOps no longer has the run. pipeline_url links to the run in Azure DevOps. Read-only: does not start, modify, approve, cancel, or trigger a deployment.

get_deployment_status

Use this when the user has confirmed they want to deploy an Azure DevOps (Azure Boards) work item, ticket, bug, or user story to an environment such as QA, staging, or UAT — for example after preview_deploy, when they reply "yes", "deploy it", or "go ahead". It queues the team's existing Azure Pipeline for the Azure Repos branch linked to the ticket. Do not use this for GitHub, GitLab, Jenkins, or other CI systems, or to deploy a branch that is not linked to a work item. Deploys an Azure DevOps work item — exactly like the deploy button on the ticket. Give it only the work item ID. BranchDeploy resolves everything else server-side: its project, its linked branch, and the pipeline + rules configured for the target environment. You never choose or pass a branch, pipeline, or environment ID — the AI cannot deploy an arbitrary branch or bypass the configured branch rules. - environmentName: pass ONLY if the user named an environment, or a previous call returned status "choose-environment". Otherwise omit it: the server picks the one environment whose branch rules allow the linked branch. The environment's name or its pipeline parameter value (e.g. "uat") both work. - branchName: pass ONLY to disambiguate when a work item has multiple linked branches; it must be one of the branches already linked to the work item. The tool refuses if the environment is not configured, the branch is not allowed by the environment's rules, or no branch is linked. This starts a real pipeline run that replaces what is currently on the target environment. It is meant to follow preview_deploy, once the user has seen the work item, branch, and environment that preview_deploy resolved and has said to go ahead. Clients signed in with BranchDeploy (OAuth) must pass the confirmationToken that preview_deploy returned; without it the call is refused with CONFIRMATION_REQUIRED.

deploy

Rewrites an existing DRAFT release note, for example to shorten it or remove wording that sounds internal. Fields left out stay as they are. Supplying items replaces the whole list, which is how entries are reordered or removed. Copy that contains a source work item ID, an Azure Boards reference (AB#123), or a source branch name is rejected with INTERNAL_REFERENCE. Only drafts can be edited. A published note can only be changed in the BranchDeploy account app, so customers never see an unreviewed edit.

update_release_note_draft

Lists recent deployments that could go into customer-facing release notes, with their work item titles, plus the release-note feeds configured for this organisation. Defaults to the last 14 days and to deployments that reached 'triggered' or 'succeeded'. Each deployment has a suggestedItemType derived from its Azure DevOps work item type: a Bug maps to "fix", an Epic or Feature to "feature". usedBy names the release note a deployment is already written up in; null means it has not been announced yet. The same work item often appears on several deployments, for example once for test and once for production. Deployment IDs and work item IDs in the result are internal references for traceability. The result also carries copyRules, the style BranchDeploy expects for customer-facing copy. Read-only: does not create, change, or publish anything.

list_release_note_candidates

Lists the deployment environments (for example QA, staging, UAT) configured in this BranchDeploy workspace, grouped by Azure DevOps project. Without a project, returns every project and its environments. The workspace name is usually not an Azure DevOps project name. Returns environment names and descriptions only; pipeline IDs and branch rules stay on the server. Deploying does not depend on this list: a work item's project and default environment are resolved on the server. Read-only: does not start, modify, approve, cancel, or trigger a deployment.

list_environments

Lists release notes that already exist in BranchDeploy, newest first, with their status and IDs, including notes created in earlier conversations. Filter by status: "draft" for unfinished notes, "published" for what customers can already see, "archived" for withdrawn ones. Read-only: does not create, change, or publish anything.

list_release_notes

Previews deploying an Azure DevOps (Azure Boards) work item — ticket, bug, or user story — to an environment such as dev, QA, test, staging, UAT, or preview, without starting anything. Also shows which branch and pipeline a ticket would deploy. The server resolves the work item's project and title, its linked Azure Repos branch (or a linked pull request's source branch), the target environment, the Azure Pipeline that would run, whether the stored credential has permission, and whether the environment's branch rules allow the branch. When the deployment is allowed, also returns a short-lived confirmationToken that the deploy tool accepts for this work item, branch, and environment. Azure DevOps only: GitHub, GitLab, Jenkins, and other CI systems are not supported, nor are branches that are not linked to a work item. Read-only: does not start, modify, approve, cancel, or trigger a deployment.

preview_deploy

Returns the exact public JSON customers would receive if this release note were published now, without publishing it, plus a short-lived confirmationToken that publish_release_note requires. The token is tied to the previewed content. If the draft changes afterwards, the token stops working and a new preview is needed, so a publish always matches a version that was previewed. Read-only: does not publish anything or make the note visible to customers.

preview_release_note

Publishes a release note to customers. Once published, the note is served from BranchDeploy's public JSON feed and the customer's app can display it immediately. Requires the confirmationToken that preview_release_note returned for this exact content. If the note changed after the preview, the call fails and the token is not accepted.

publish_release_note