Skip to main content
Glama
Azure DevOps MCP Server
by billg118

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
LOG_LEVELNoLogging level: debug, info, warn, or error.info
AZURE_CLIENT_IDNoAzure AD application (client) ID. Only needed when authenticating with a service principal via Azure Identity.
AZURE_TENANT_IDNoAzure AD tenant ID. Only needed when authenticating with a service principal via Azure Identity.
AZURE_DEVOPS_PATNoPersonal Access Token. Required only when AZURE_DEVOPS_AUTH_METHOD is 'pat' (the only supported method for Azure DevOps Server / on-premises).
AZURE_CLIENT_SECRETNoAzure AD client secret. Only needed when authenticating with a service principal via Azure Identity.
AZURE_DEVOPS_ORG_URLYesFull 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_VERSIONNoREST api-version used by tools that call the REST API directly.7.1
AZURE_DEVOPS_AUTH_METHODNoAuthentication method: 'pat', 'azure-identity', or 'azure-cli' (case-insensitive).azure-identity
AZURE_DEVOPS_DEFAULT_PROJECTNoDefault 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

CapabilityDetails
tools
{}
resources
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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.

  • Provide plain branch names (no "refs/heads/").

  • ⚠️ Each file path may appear only once per commit request—combine all edits to a file into a single change entry.

  • Prefer multiple commits when you have sparse or unrelated edits; smaller focused commits keep review context clear.

🎯 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:

{
  "changes": [{
    "path": "src/api/services/function-call.ts",
    "search": "return axios.post(apiUrl, payload, requestConfig);",
    "replace": "return axios.post(apiUrl, payload, requestConfig).then(r => { processResponse(r); return r; });"
  }]
}

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:

  • Each patch MUST have complete hunk headers: @@ -oldStart,oldLines +newStart,newLines @@

  • CRITICAL: Every @@ marker MUST include line numbers. Do NOT use @@ without line ranges.

  • Include 3-5 context lines before and after changes.

  • For deletions: --- a/filepath and +++ /dev/null

  • For additions: --- /dev/null and +++ b/filepath

Example unified diff:

{
  "changes": [{
    "patch": "diff --git a/file.yaml b/file.yaml\n--- a/file.yaml\n+++ b/file.yaml\n@@ -4,7 +4,7 @@ spec:\n spec:\n   type: ClusterIP\n   ports:\n-    - port: 8080\n+    - port: 9090\n       targetPort: http\n"
  }]
}
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.

  • Surfaces pipeline and run identifiers so you can jump straight to the blocking validation.

  • Pair with pipeline tools (e.g., get_pipeline_run, pipeline_timeline) to inspect failures in depth.

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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

C2.9/5.0

Scored across 49 tools

Disambiguation3/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness3/5

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.

Maintenance

ActivityActive
ResponsivenessSyncing