Azure DevOps MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level: debug, info, warn, or error. | info |
| AZURE_CLIENT_ID | No | Azure AD application (client) ID. Only needed when authenticating with a service principal via Azure Identity. | |
| AZURE_TENANT_ID | No | Azure AD tenant ID. Only needed when authenticating with a service principal via Azure Identity. | |
| AZURE_DEVOPS_PAT | No | Personal Access Token. Required only when AZURE_DEVOPS_AUTH_METHOD is 'pat' (the only supported method for Azure DevOps Server / on-premises). | |
| AZURE_CLIENT_SECRET | No | Azure AD client secret. Only needed when authenticating with a service principal via Azure Identity. | |
| AZURE_DEVOPS_ORG_URL | Yes | Full URL to your Azure DevOps organization or Server collection (e.g. https://dev.azure.com/your-organization or https://server:8080/tfs/DefaultCollection). | |
| AZURE_DEVOPS_API_VERSION | No | REST api-version used by tools that call the REST API directly. | 7.1 |
| AZURE_DEVOPS_AUTH_METHOD | No | Authentication method: 'pat', 'azure-identity', or 'azure-cli' (case-insensitive). | azure-identity |
| AZURE_DEVOPS_DEFAULT_PROJECT | No | Default project to use when none is specified. |
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 | {} |
| resources | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_meA | Get details of the authenticated user (id, displayName, email) |
| list_organizationsA | List all Azure DevOps organizations accessible to the current authentication |
| list_projectsC | List all projects in an organization |
| get_projectC | Get details of a specific project |
| get_project_detailsB | Get comprehensive details of a project including process, work item types, and teams |
| get_repositoryC | Get details of a specific repository |
| get_repository_detailsC | Get detailed information about a repository including statistics and refs |
| list_repositoriesC | List repositories in a project |
| get_file_contentC | Get content of a file or directory from a repository |
| get_all_repositories_treeA | Displays a hierarchical tree view of files and directories across multiple Azure DevOps repositories within a project, based on their default branches |
| get_repository_treeB | Displays a hierarchical tree view of files and directories within a single repository starting from an optional path |
| create_branchC | Create a new branch from an existing one |
| create_commitA | Create a commit on an existing branch using file changes.
🎯 RECOMMENDED: Use the SEARCH/REPLACE format (much easier, no line counting!). Option 1: SEARCH/REPLACE format (EASIEST) Simply provide the exact text to find and replace: The server fetches the file, performs the replacement, and generates the diff automatically. No line counting, no hunk headers, no context lines needed! Option 2: UNIFIED DIFF format (Advanced) If you prefer full control, provide complete unified diffs:
Example unified diff: |
| list_commitsB | List recent commits on a branch including file-level diff content for each commit |
| list_work_itemsC | List work items in a project |
| get_work_itemC | Get details of a specific work item |
| create_work_itemC | Create a new work item |
| update_work_itemC | Update an existing work item |
| manage_work_item_linkC | Add or remove links between work items |
| get_work_item_commentsC | Get comments and discussion history for a specific work item |
| create_work_item_attachmentA | Upload a file and attach it to a work item. The file is read from the local filesystem, uploaded to Azure DevOps, and linked to the specified work item. |
| get_work_item_attachmentB | Download an attachment from Azure DevOps and save it to the local filesystem. The attachment ID can be obtained from the work item relations. |
| delete_work_item_attachmentA | Delete an attachment from a work item. The attachment ID can be obtained from the work item relations. |
| search_codeC | Search for code across repositories in a project |
| search_wikiC | Search for content across wiki pages in a project |
| search_work_itemsC | Search for work items across projects in Azure DevOps |
| create_pull_requestC | Create a new pull request, including reviewers, linked work items, and optional tags |
| get_pull_requestB | Get a pull request by ID (no repositoryId required; best for Azure DevOps Server where PR IDs are project-scoped) |
| list_pull_requestsC | List pull requests in a repository |
| get_pull_request_commentsC | Get comments from a specific pull request |
| add_pull_request_commentC | Add a comment to a pull request (repositoryId optional; derived from pullRequestId when omitted) |
| update_pull_requestB | Update an existing pull request with new properties, manage reviewers and work items, and add or remove tags |
| get_pull_request_changesA | Get the files changed in a pull request, their unified diffs, source/target branch names, and the status of policy evaluations |
| get_pull_request_checksA | Summarize the latest status checks and policy evaluations for a pull request.
|
| update_pull_request_thread_statusC | Update the status of a comment thread in a pull request (repositoryId optional; derived from pullRequestId when omitted) |
| list_pipelinesC | List pipelines in a project |
| get_pipelineC | Get details of a specific pipeline |
| list_pipeline_runsC | List recent runs for a pipeline |
| get_pipeline_runC | Get details for a specific pipeline run |
| download_pipeline_artifactA | Download a file from a pipeline run artifact and return its textual content |
| pipeline_timelineB | Retrieve the timeline of stages and jobs for a pipeline run, to reduce the amount of data returned, you can filter by state and result |
| get_pipeline_logC | Retrieve a specific pipeline log using the timeline log identifier |
| trigger_pipelineC | Trigger a pipeline run |
| get_wikisC | Get details of wikis in a project |
| get_wiki_pageC | Get the content of a wiki page |
| create_wikiC | Create a new wiki in the project |
| update_wiki_pageC | Update content of a wiki page |
| list_wiki_pagesC | List pages within an Azure DevOps wiki |
| create_wiki_pageA | Create a new page in a wiki. If the page already exists at the specified path, it will be updated. |
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 49 tools
Several near-duplicate pairs create real ambiguity: get_project vs get_project_details, get_repository vs get_repository_details, get_repository_tree vs get_all_repositories_tree, and get_pull_request_checks vs get_pull_request_changes. Descriptions do distinguish them (e.g. 'comprehensive details' vs basic), but an agent must read carefully to pick correctly. The bulk of the remaining tools (work items, pipelines, wikis) are cleanly separated by resource.
Almost everything follows a verb_noun snake_case pattern (list_*, get_*, create_*, update_*, search_*, manage_*). Minor deviations exist: get_me uses a pronoun object, get_all_repositories_tree adds an extra qualifier, and pipeline_timeline drops the verb entirely in favor of noun-first naming. These are readable but break the otherwise predictable convention.
49 tools is well beyond a manageable surface for one server, spanning six distinct domains (orgs/projects, repos/git, work items, search, pull requests, pipelines, wikis). The volume plus the redundant *_details siblings suggests the surface could be consolidated substantially. Agents will struggle to route reliably across this many options.
Read/create/update coverage is broad and genuinely deep (work item attachments and links, PR threads and checks, pipeline logs and timelines, wiki pages). However, delete operations are notably missing across most domains: no delete_work_item, delete_branch, delete_repository, delete_pull_request, or delete_wiki_page — only attachments have a delete tool. These gaps will force agents to declare dead ends on common lifecycle tasks.