Azure DevOps MCP Server

The Azure DevOps MCP Server is Microsoft's official Model Context Protocol server for Azure DevOps. According to the official repository, it gives AI assistants secure access to work items, pull requests, builds, test plans, and documentation from an Azure DevOps organization, instead of relying solely on generic model knowledge. The official repository lives at https://github.com/microsoft/azure-devops-mcp (exactly 2,029 stars and 652 forks per the GitHub API on 2026-09-25, MIT licensed, actively maintained, last pushed 2026-09-24), with corresponding product documentation in Microsoft's Azure DevOps handbook on learn.microsoft.com. The npm package @azure-devops/mcp is currently at version 2.10.0 and is published directly by Microsoft Corporation.

What is the Azure DevOps MCP Server?

Unlike the broader Azure MCP Server already listed in the catalog, which manages general Azure cloud resources, this server focuses exclusively on Azure DevOps: projects and teams, work items (bugs, tasks, user stories, features), pull requests together with linked work items, build and pipeline status, test plans, and wiki content. According to the official documentation, this lets you ask questions such as "What's blocking our current sprint?" or "Which pull requests need my review?" and get answers grounded in real, current data from your own organization instead of generic responses.

Hosted or local

Microsoft offers two operating modes. The hosted remote server runs at an organization-specific address over Streamable HTTP, requires no local installation, and is updated by Microsoft itself; however, it requires the Azure DevOps organization to be backed by a Microsoft Entra tenant — standalone Microsoft account (MSA) organizations aren't supported for the remote server according to the provider. The local server instead runs on your own machine via npx -y @azure-devops/mcp {organization} and is explicitly the recommended path, per the official documentation, for clients such as Claude Desktop, Claude Code, Cursor, and Codex, since these don't support the dynamic OAuth client registration flow the remote server needs. Running the local server requires Node.js 20 or later and an active Azure DevOps organization.

Features and tools

According to the README, the tools are grouped into nine domains: core, work, work-items, search, test-plans, repositories, wiki, pipelines, and advanced-security. This covers the full project workflow, from sprint planning through backlog prioritization and code-review context to daily standup preparation — each illustrated with concrete example workflows in the official documentation.

Authentication

By default, the local server uses interactive browser-based sign-in with a Microsoft account. The --authentication parameter can instead select an existing Azure CLI session (azcli), an environment variable, or a personal access token. The remote server authenticates exclusively through Microsoft Entra.

Security and privacy

According to the provider, the server itself makes no external API calls outside Azure DevOps, users retain full control over what data the agent can access, and sensitive project data does not leave the user's network in an uncontrolled way, per Microsoft. One nuance worth noting: retrieved data necessarily flows into requests sent to the connected AI model, which — depending on the client in use — may be a separate, external provider; that data path sits outside the MCP server's own control.

Who should use it?

The server is especially useful for teams actively using Azure DevOps for boards, repos, pipelines, or test management who want their AI assistant working from real, current project data instead of guesswork. Anyone who instead needs to manage general Azure cloud resources such as virtual machines or storage accounts should use the Azure MCP Server already listed in the catalog.

FAQ

Is the Azure DevOps MCP Server free? Yes, according to the official documentation the server itself is free to use. However, standard pricing for your Azure DevOps organization still applies for licenses and data access.

Do I need the remote or the local server for Claude Code? For Claude Code, Claude Desktop, Cursor, and Codex, Microsoft explicitly recommends the local server via npx, since these clients don't support the OAuth flow required by the remote server.

An active Azure DevOps organization. For the local server: Node.js 20+ and a compatible MCP client. For the hosted remote server: the organization must be backed by a Microsoft Entra tenant (standalone MSA organizations aren't supported).

For Claude Code: claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp {organization} (replace with your organization name). For Claude Desktop: under "File > Settings > Developer > Edit Config", add the local server with command npx and arguments -y @azure-devops/mcp {organization}, restart Claude Desktop, and confirm the "ado" connector. Default authentication is interactive browser sign-in; use --authentication azcli to reuse an existing az login session instead.

claude mcp add --transport stdio azure-devops -- npx -y @azure-devops/mcp {organization}

Local server: interactive browser sign-in with a Microsoft account (default), or alternatively Azure CLI (azcli), an environment variable, or a personal access token. Remote server: Microsoft Entra only, requires an Entra-backed organization.

Access to projects, work items, pull requests, builds/pipelines, test plans, repositories, and wiki content of the connected Azure DevOps organization, scoped to the signed-in account's permissions. According to the provider, scope is controllable by the user via the selected domains and account permissions.

The local server runs as a process on the user's own machine and communicates directly with the organization's Azure DevOps REST API; the remote server runs as a Microsoft-hosted endpoint. Retrieved project data is passed on to the MCP client and its connected AI model.

According to the provider, there are no external API calls outside Azure DevOps and users retain full control over data access. Because the server can also support write operations (for example triggering pipelines), account permissions should be kept deliberately minimal. Retrieved project and code data flows into requests sent to the connected AI model.