Azure Image Pipeline MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AZDO_PAT | Yes | Azure DevOps Personal Access Token with minimum required scope for pipeline access. | |
| MCP_ALLOW_QUEUE_RUN | No | Set to 'true' to enable the queue_image_pipeline tool. Queueing is disabled by default. | false |
| MCP_ALLOWED_PARAMETERS | No | Comma-separated list of allowed template parameters for queueing a pipeline run. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_recent_image_runsC | List recent runs for the configured Azure DevOps image pipeline. |
| get_image_run_statusB | Get pipeline and build status for one image-pipeline run. |
| get_image_run_evidenceC | List evidence artifacts and report which expected image-release artifacts are missing. |
| queue_image_pipelineB | Queue an image pipeline only when writes are enabled and the exact confirmation token is supplied. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct resource+action: listing recent runs, fetching status of one run, gathering evidence artifacts, and queueing a pipeline. No two tools overlap in purpose, so misselection is unlikely.
All four names follow a consistent verb_noun pattern (get_image_run_*, list_recent_image_runs, queue_image_pipeline) with a shared 'image' domain prefix. Predictable and readable throughout.
Four tools is on the lean side but fits the narrow monitoring-and-queueing scope of an image pipeline. Each tool earns its place, though one or two more (e.g. logs/cancel) could round it out.
The surface covers the core lifecycle: discover runs, inspect status, gather release evidence, and trigger a run under a guarded confirmation. Minor gaps like canceling/retrying a run or fetching raw logs are workable around.