mcp-azure-devops
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_projectsA | List the projects in the Azure DevOps organization that pass the allowlist. Returns each project's id, name, state, and whether it is marked protected (readable but never mutated). Start here to discover valid project names. |
| get_projectA | Fetch the full details (id, description, visibility, state, capabilities) of a single project. |
| list_teamsA | List the teams defined in a project, with their ids and names. Use a team id/name with the team-scoped tools. |
| list_team_membersA | List the members (identities: display name and unique name) of a specific team within a project. |
| list_processesA | List the organization's process templates (Agile, Scrum, CMMI, or inherited) with their ids. Pass one of these ids as the process when creating a project. |
| query_work_itemsA | Run a Work Item Query Language (WIQL) query against a project and return the matching work-item ids (fetch fields with get_work_item). Example: SELECT [System.Id] FROM WorkItems WHERE [System.State] = 'Active'. |
| get_work_itemA | Fetch a single work item by id, including all of its fields (title, state, assignee, tags, …). |
| list_iterationsA | List a team's iterations (sprints), each with its path and start/finish dates. |
| list_repositoriesA | List the Git repositories in a project, with their ids, names, and default branches. |
| list_branchesA | List the branches (refs/heads) of a Git repository, with the commit each one points at. |
| list_pull_requestsA | List pull requests in a repository, optionally filtered by status (active by default). |
| get_pull_requestA | Fetch a single pull request by id, including its source/target branches, status, and reviewers. |
| list_pipelinesA | List the pipelines defined in a project, with their ids and names. Use a pipeline id with run_pipeline. |
| list_buildsA | List recent builds / pipeline runs in a project, most recent first, with their status and result. |
| get_buildA | Fetch a single build / pipeline run by id, with its status, result, and timing. |
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 15 tools
Each tool targets a distinct Azure DevOps resource or action: projects, teams, team members, processes, work items, iterations, repositories, branches, pull requests, pipelines, and builds. list_* and get_* pairs are clearly complementary rather than overlapping, and query_work_items vs get_work_item is a clear search-then-fetch workflow.
Tool names follow a consistent list_<resource> and get_<resource> snake_case convention, with query_work_items as the only special-case verb. No mixed casing or vague verbs like 'process' or 'run' appear, making the naming predictable and easy to navigate.
Fifteen tools is at the upper edge of the well-scoped range but still appropriate: each tool covers a meaningful read operation on a distinct Azure DevOps entity, and none feel redundant. The count reflects a focused read-only browsing surface rather than an unwieldy grab bag.
The set covers read-only browsing across major Azure DevOps entities, but it has no create, update, delete, or run operations at all. This is especially problematic because list_processes references creating a project and list_pipelines references run_pipeline, yet neither create_project nor run_pipeline is exposed, leaving agents with dead ends and incomplete workflows.