Azure DevOps MCP Server
Gives AI agents MCP-based access to Azure DevOps projects, work items, repos, pipelines, and wikis.
- Source repo
- microsoft/azure-devops-mcp
- Stars
- ★ 2.1k
- Last updated
- 1d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 61/100 · Some gaps
At a glance
- Works with
- Portable with changesCodex · Claude Code (Partial support)
- You'll need
- Typical use
- A developer in VS Code using GitHub Copilot Agent mode who wants to ask which ADO work items are assigned to them without leaving the chat.
- Main limitation
- Tied to Azure DevOps and Microsoft accounts; teams on other code hosting platforms get no value.
- Source review
- 61/100 · Some gaps
What does this agent do, and when should you use it?
Azure DevOps MCP Server is Microsoft's open-source Model Context Protocol server that exposes Azure DevOps context to AI agents. It ships in two forms: a recommended remote hosted server at https://mcp.dev.azure.com/{organization} over HTTP with no installation, and an optional local server run via npx @azure-devops/mcp over stdio. Each tool handles one focused Azure DevOps task — the server is a thin layer over the REST APIs while the agent handles higher-level reasoning. It is MIT-licensed, and the docs state the remote server will eventually replace the local one, with new features landing there first. Guidance covers VS Code, Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode, and Kilo Code as supported clients.
The server wraps Azure DevOps REST APIs as MCP tools the agent invokes during a conversation: list ADO projects; list builds, repos, test plans, teams, and iterations for a project such as 'Contoso'; query work items in the current iteration or for a given project and team; list all wikis in a project; create, update, and read wiki pages like '/Architecture/Overview'. The local server supports loading tool groups by domain with the -d flag — core, work, work-items, search, test-plans, repositories, wiki, pipelines, and advanced-security — and accepts ado_mcp_project and ado_mcp_team environment variables as defaults. Tool results are returned to the agent, which turns them into answers or action suggestions.
- A developer in VS Code using GitHub Copilot Agent mode who wants to ask which ADO work items are assigned to them without leaving the chat.
- A project manager who needs to list iterations, teams, and test plans for the 'Contoso' project before a stand-up.
- A documentation maintainer asking the agent to create or update wiki pages such as '/Getting Started' with onboarding content.
- A user on a client with strict tool limits who loads only core, work, and work-items via -d to keep the tool list manageable.
- A team on Claude Code, Codex, or Cursor that wants a single protocol to plug Azure DevOps context into its own agents.
- A team that prefers zero install and wires up the remote MCP Server with a single URL entry in .vscode/mcp.json.
How do you install or deploy this agent?
Start with the remote server. Create .vscode/mcp.json in your project and add this configuration, replacing {organization} with your Azure DevOps organization name.
{
"servers": {
"ado-remote-mcp": {
"url": "https://mcp.dev.azure.com/{organization}",
"type": "http"
}
},
"inputs": []
}Install the local server only if your scenario specifically needs a local stdio connection. Prerequisites are VS Code (or VS Code Insiders) and Node.js 20 or later. Configure it from npm like this:
{
"servers": {
"ado": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure-devops/mcp", "{organization}"]
}
}
}For nightly builds, replace @azure-devops/mcp with @azure-devops/mcp@next.
How do you use this agent?
After saving .vscode/mcp.json, start the server from the MCP view in VS Code (ado-remote-mcp for remote, ado for local), sign in with a Microsoft account that has access to the organization, then run a prompt such as:
List ADO projectsTo help the agent pick the right tools, add .github/copilot-instructions.md to your project:
This project uses Azure DevOps. Always check whether the Azure DevOps MCP server has a tool relevant to the user's request.The local server can be trimmed by domain — for example, only core, work, and work-items:
{
"servers": {
"ado_with_filtered_domains": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@azure-devops/mcp", "{organization}", "-d", "core", "work", "work-items"]
}
}
}You can also set default project and team via the ado_mcp_project and ado_mcp_team environment variables in .vscode/mcp.json.
What are this agent's strengths and limitations?
- A hosted remote MCP Server needs no installation — a single URL entry in
.vscode/mcp.jsongets you connected. - The optional local stdio server supports domain filtering (
core,work,work-items,wiki,pipelines, and more) to work around client tool limits. - Maps directly onto Azure DevOps REST APIs, covering projects, work items, repos, pipelines, test plans, and wikis.
- The docs name concrete supported clients: VS Code, Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode, and Kilo Code.
- MIT-licensed with a contribution guide and issue templates for bug reports and feature requests.
- Tied to Azure DevOps and Microsoft accounts; teams on other code hosting platforms get no value.
- The remote server is still in preview and is slated to replace the local server, so existing local users face a migration.
- The local server requires Node.js 20 or later and pulls
@azure-devops/mcpvia npx, so it needs network access. - The README gives only a high-level overview of domains; the full local tool list lives in
docs/TOOLSET.md. - Tool selection depends on the agent, and the docs recommend adding
copilot-instructions.mdto steer it toward ADO tools.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Azure DevOps MCP Server This agent | 61 · Some gaps | — | ★ 2.1k | 1d ago | TypeScript | — |
| Argot Repository Style Analyzer | 93 · Excellent | CLIFree | ★ 51 | 1mo ago | Rust | Claude Code |
| OSS Autopilot | 83 · Good | Agent plugin / skillFree | ★ 22 | 1d ago | TypeScript | Claude Code · Claude.ai |
| Happier | 82 · Good | Desktop appFree + model costs | ★ 2k | today | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Trust: domain filtering (-d) and on-demand tool groups show a least-privilege intent, but all domains load by default and write operations (create/update wiki pages, update build stage) show no enforced confirmation at the tool layer, so least_privilege=2 and user_confirmation=1. Data flow: README and TROUBLESHOOTING document auth modes (OAuth/azcli/envvar/PAT) and token env vars, but data destinations are not systematically described, data_flow_transparency=2. Sensitive data: PAT via env var and Entra ID restriction are noted, but token storage and log redaction are not emphasized, sensitive_data_handling=2. Dependency security: CI pins actions by SHA, uses harden-runner, CodeQL and npm ci, but package.json uses range versions and no audit/vulnerability scanning is described, dependency_security=2. External effects: write operations exist with no rollback/undo guidance, external_effects=1 and rollback=1. Source attribution: LICENSE, package.json author, SECURITY.md and trademark notice are clear, source_attribution=2.
Reliability: README recommends the remote server while FAQ still states only the local version is supported, a clear inconsistency, self_consistency=1. Dependency availability: npm publication, Node 20+ requirement, optional deps and CI build flow are explicit, dependency_availability=2. Failure messages: TROUBLESHOOTING gives symptoms and root causes for common errors (wrong org name, headless auth failure, multi-tenant TF400813), failure_messages=2.
Adaptability: README covers VS Code, Visual Studio, Claude Code, Cursor and other clients, audience_and_scenarios=2. Capability boundaries: FAQ states Azure DevOps Services only, single org, no personal accounts, capability_boundaries=2. Trigger precision: copilot-instructions guidance and domain filtering to control tool count, trigger_precision=2. Environment fit: docs cover WSL2/SSH/Docker/CI headless auth alternatives, environment_fit=2.
Convention: README has a clear TOC and docs are split into files, information_architecture=2. Install notes are thorough (remote and local, npm, domains, project/team defaults), install_notes=3. Naming stability: package and bin names are consistent, but docs mix npx @azure-devops/mcp and mcp-server-azuredevops invocations, naming_stability=2. Examples and FAQ: present, though example files are not expanded in the evidence, examples_and_faq=2. Known limitations: FAQ and TROUBLESHOOTING list limits, known_limitations=2. License: full MIT text, license=3. Versioning/changelog: package.json has a version and CI checks sync, but no CHANGELOG is present, versioning_changelog=1. Maintenance responsibility: SECURITY.md, contribution guide and Microsoft ownership are clear, maintenance_responsibility=2.
Effectiveness: tools are focused on single ADO tasks and outputs are wrapped by content-safety, output_usability=2. Marginal value: provides ADO context to agents, but the remote server will replace the local one, marginal_value=2. Cost benefit: requires Node and auth setup, domain filtering reduces tool-count cost, cost_benefit=2.
Verifiability: README claims largely point to external Microsoft Learn docs with limited in-repo evidence, claim_traceability=1. Cross-source corroboration: README, FAQ and TROUBLESHOOTING disagree on remote server status, cross_source_corroboration=1. Fact/inference separation: docs are mostly operational with no explicit evidence labeling for security/reliability claims, fact_inference_separation=1.
- README recommends the remote server while FAQ still says only the local version is supported; confirm current support status before use.
- Write operations (create/update wiki, update build stage) show no enforced confirmation or rollback at the tool layer; agent mistakes may cause irreversible external effects.
- PAT is passed via env var and docs do not emphasize token storage or log redaction; secure env vars and logs yourself.
- Dependencies use range versions and no dependency vulnerability audit is described; run npm audit independently.
- This is a static source review with no code or tests executed; confidence is low.