# azure-devops-mcp: the MCP server that connects AI agents to Azure DevOps projects and tools > azure-devops-mcp is a Microsoft-published MCP server that connects AI agents to Azure DevOps projects, repositories, work items, pipelines and wikis; a hosted remote server requires no installation while a local server via npx handles stdio connections. The remote server is in a preview period, yet Microsoft recommends it over the local server. **microsoft/azure-devops-mcp** — The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents. - Repository: https://github.com/microsoft/azure-devops-mcp - Stars: 2,055 · Forks: 661 - Language: TypeScript - License: MIT - Published: 2026-10-11 · Updated: 2026-10-11 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-azure-devops-mcp ## azure-devops-mcp gives AI agents a structured interface to Azure DevOps REST APIs This project connects AI agents to Azure DevOps through the Model Context Protocol, exposing project data, repository contents, work items, pipelines, test plans and wiki pages as callable MCP tools. Each tool handles a focused Azure DevOps task, and the server provides a thin layer over the REST APIs while the AI agent handles higher-level reasoning. 2 deployment paths exist. A hosted remote server at Microsoft's infrastructure requires no local installation. A local server run via npx handles stdio connections for AI clients that require that transport. The README recommends the remote server for most users and says to use the local server only when a local stdio connection is specifically required. Prompt examples from the README give a sense of what the tools cover: listing projects, listing repositories and builds for named projects, listing test plans and iterations, and creating or updating wiki pages. ## The remote server needs only a .vscode/mcp.json entry and is the recommended path Start by creating .vscode/mcp.json in your project. Replace {organization} with your Azure DevOps organization name: ```json { "servers": { "ado-remote-mcp": { "url": "https://mcp.dev.azure.com/{organization}", "type": "http" } }, "inputs": [] } ``` Save the file, start the server from the MCP view in VS Code, then try a prompt like 'List ADO projects'. No Node.js requirement applies to the remote path, and no npm package is installed locally. One detail the README names explicitly: the remote server is currently in a preview period. During that preview period, issues are tracked through the GitHub repository via the Remote MCP Server issue template. That preview status appears later in the document than the strong recommendation to use the remote server, and a reader scanning only the introduction would miss it. ## Local server installation requires Node.js 20 and uses npx @azure-devops/mcp Prerequisites for the local server are VS Code or VS Code Insiders, and Node.js 20 or later. After adding the server entry to .vscode/mcp.json, starting the ado server from the MCP view prompts for an Azure DevOps organization name, which is passed to the server at startup. On npm the package name is @azure-devops/mcp. With the local server running, sign-in uses a Microsoft account that has access to the selected Azure DevOps organization. To switch to nightly builds, replacing @azure-devops/mcp with @azure-devops/mcp@next in the args array selects the nightly channel. 8 named clients support the local server beyond the basic VS Code with GitHub Copilot path: Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode and Kilo Code. Setup steps for those additional clients appear in docs/GETTINGSTARTED.md rather than the main README. ## 9 domains and the -d flag reduce tool exposure for clients with limits Without domain filtering, the local server loads all available tools. Adding -d to the args array followed by domain names loads only the specified subsets. 9 domains are defined: core, work, work-items, search, test-plans, repositories, wiki, pipelines, and advanced-security. core must always be included so the agent can retrieve project information. The README warns that omitting core breaks tool functionality. Omitting -d entirely loads all 9 domains. Domain filtering addresses a concrete constraint: some AI clients have limits on how many tools they can handle at once. Loading fewer domains keeps the tool list shorter. For a workflow that only touches work items, using -d core work work-items reduces the total tools visible to the agent without affecting the tasks it needs to perform. ## Setting ado_mcp_project and ado_mcp_team to skip repeated project selection When tools repeatedly prompt for the Azure DevOps project name, setting defaults in .vscode/mcp.json removes those prompts. ado_mcp_project and ado_mcp_team are the environment variables that carry the default values: ```json { "servers": { "ado": { "type": "stdio", "command": "npx", "args": ["-y", "@azure-devops/mcp", "myorg", "--authentication", "azcli"], "env": { "ado_mcp_project": "Contoso", "ado_mcp_team": "Fabrikam Team" } } } } ``` This example hard-codes the organization name as myorg in the args array rather than using a promptString input. Passing --authentication azcli routes sign-in through the Azure CLI instead of a browser prompt. For better tool selection by the agent, the README recommends adding .github/copilot-instructions.md with one line of instruction. The README's proposed text is: 'This project uses Azure DevOps. Always check whether the Azure DevOps MCP server has a tool relevant to the user's request.' ## The remote server is in preview despite being the recommended starting point A tension runs through the README's structure. At the top, the README tells users to use the Remote MCP Server instead of the local server because it requires no installation and gets new features first. Further down, under the remote server section, it states that during the preview period issues are tracked through the repository. Those 2 statements are in different sections of the README and easy to read in isolation. For the local server, the README is direct about the direction of travel: new development will focus on the remote server, the local server remains supported, and existing local server users should begin planning their migration. The local server's HTTP transport is incompatible with AI clients that only support stdio. For those clients, the local server is the only documented path even after the remote server reaches general availability. ## 8 supported clients, nightly builds, and the pinned inspector at port 6274 Debugging the local server uses the inspect script in package.json, which launches @modelcontextprotocol/inspector@0.21.0 against the running server. The script sets ALLOWED_ORIGINS to http://127.0.0.1:6274 and opens the inspector on that port. The inspector version is pinned to 0.21.0 rather than floating to latest. For nightly builds, the @azure-devops/mcp@next tag on npm is the install path. The README does not describe the nightly release cadence or how to roll back from a nightly to a stable version if the nightly introduces a regression. Upgrading between stable minor versions of the local server is a matter of updating the package reference in the args array. The server is stateless and carries no local database, so there is no schema migration on update. New tools added in a minor version appear automatically once the package is updated, but new domains require an explicit -d entry if domain filtering is active. ## Conclusion azure-devops-mcp is worth adopting when you have AI agents that need structured access to Azure DevOps projects, repositories, work items or pipelines, and your setup supports MCP. Use the remote server unless you specifically need a local stdio connection; no Node.js install is required for the remote path. Avoid the local server for new projects: the README states new development will focus on the remote server and recommends that existing local server users begin planning migration. v2.10.0 was released on 2026-09-09. Before starting, verify the remote server has exited preview if stability matters for your deployment. ## FAQ ### What is the Azure DevOps MCP Server? azure-devops-mcp is a Microsoft-published MIT-licensed server that gives AI agents access to Azure DevOps through the Model Context Protocol. It covers projects, repositories, work items, pipelines, test plans and wikis. ### How do I use the remote Azure DevOps MCP Server? Create .vscode/mcp.json with a server entry pointing to https://mcp.dev.azure.com/{organization}, replace {organization} with your organization name, then start the server from the MCP view in VS Code. No Node.js installation is required. ### What domains does azure-devops-mcp support? The local server defines 9 domains: core, work, work-items, search, test-plans, repositories, wiki, pipelines and advanced-security. Pass them with the -d flag to load only the relevant tool groups. core must always be included. ### Does azure-devops-mcp work with Claude Code? Claude Code is listed in the README as one of the supported clients for the local server. Setup steps for Claude Code appear in docs/GETTINGSTARTED.md. ### What is the difference between the remote and local Azure DevOps MCP Server? The remote server uses HTTP transport, requires no installation, and is recommended for most users. It is currently in a preview period. The local server uses stdio transport, requires Node.js 20, and is needed only when a stdio connection is specifically required. ## Sources - [Issues](https://github.com/microsoft/azure-devops-mcp/issues) - [License: MIT](https://github.com/microsoft/azure-devops-mcp/blob/main/LICENSE) - [microsoft/azure-devops-mcp on GitHub](https://github.com/microsoft/azure-devops-mcp) - [README](https://github.com/microsoft/azure-devops-mcp/blob/main/README.md) - [Releases](https://github.com/microsoft/azure-devops-mcp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-azure-devops-mcp