Azure Image Pipeline MCP
# Azure Image Pipeline MCP
A focused Model Context Protocol server for an Azure VM image-baking pipeline. It exposes three read-only tools for pipeline runs, build status and release evidence, plus one strongly guarded tool for queueing a pipeline run.
## Why a focused server?
Microsoft provides an official Azure DevOps MCP server. Use that server for broad Azure DevOps access. This sample is intentionally narrower: it demonstrates how to present image-release concepts as domain tools, enforce a parameter allow-list and keep pipeline queueing disabled by default.
## Tools
- `list_recent_image_runs`
- `get_image_run_status`
- `get_image_run_evidence`
- `queue_image_pipeline` (disabled by default)
## Prerequisites
- Python 3.10+
- `uv` or `pip`
- Azure DevOps project and pipeline access
- For local development, an Azure DevOps PAT with the minimum required scope
## Run locally
```bash
cp .env.example .env
# Edit .env with non-secret settings; inject AZDO_PAT through your shell or secret store.
uv sync --extra dev
uv run mcp dev src/azure_image_mcp/server.py
```
To use stdio from VS Code, retain `.vscode/mcp.json`, restart VS Code, and start the server from the MCP server controls.
## Safe write behaviour
Queueing remains blocked unless both conditions are met:
1. `MCP_ALLOW_QUEUE_RUN=true`
2. The caller supplies the exact confirmation value `QUEUE_IMAGE_PIPELINE`
The server also rejects template parameters outside `MCP_ALLOWED_PARAMETERS`. These controls do not replace Azure DevOps checks, approvals, branch policies, environments or service-connection permissions.
## Test
```bash
uv sync --extra dev
uv run pytest -q
```
The test suite uses mocked HTTP responses and does not contact Azure DevOps.
## Example prompts
- "Show the latest 10 image pipeline runs."
- "Get status and source commit for image run 1234."
- "Which expected evidence artifacts are missing from run 1234?"
- "Queue a Java 21 CIS image build in UK South." The host should first display parameters and request explicit confirmation.
## Authentication note
This repository uses PAT authentication only as a compact local-development example. For enterprise usage, prefer Microsoft Entra-backed authentication and the hosted Azure DevOps MCP server where the client supports it.
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.