Azure DevOps MCP Server

repository·main·Indexed 23 days ago

https://github.com/microsoft/azure-devops-mcp

An MCP server for interacting with Azure DevOps Services via the Model Context Protocol. It provides tools for managing work items, backlogs, wiki pages, and repository artifacts. Supports both remote HTTP transport and local stdio setup via npx (@azure-devops/mcp). Features include domain-based tool filtering (core, work, search, pipelines, etc.) and integration with GitHub Copilot Chat. Requires Node.js 20+ and Entra ID authentication; on-premises deployments and personal Microsoft accounts are not supported.

Tokens
15K
Snippets
46
Records
78
Agent score
78%

What's inside azure-devops-mcp

  1. Filter loaded tools using Domains (local)

    main

    To prevent overwhelming the AI model and to respect client tool limits, you can use Domains to load only specific groups of related tools. Use the -d argument in the args array of your mcp.json to specify the domains you want to enable.

    Available Domains:

    • core (Recommended to always enable to fetch project-level info)
    • work
    • work-items
    • search
    • test-plans
    • repositories
    • wiki
    • pipelines
    • advanced-security

    By default, all domains are loaded if no -d flag is provided.

    {
      "inputs": [
        {
          "id": "ado_org",
          "type": "promptString",
          "description": "Azure DevOps organization name  (e.g. 'contoso')"
        }
      ],
      "servers": {
        "ado_with_filtered_domains": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@azure-devops/mcp", "${input:ado_org}", "-d", "core", "work", "work-items"]
        }
      }
    }
  2. Comply with Claude API tool and parameter naming requirements

    main

    When developing tools for the Azure DevOps MCP server, you must adhere to strict naming constraints required by the Claude API. Failure to comply will result in 400 errors during API requests.

    Naming Constraints

    • Pattern: ^[a-zA-Z0-9_.-]{1,64}$
    • Allowed Characters: Alphanumeric (a-z, A-Z, 0-9), underscores (_), dots (.), and hyphens (-).
    • Forbidden: Spaces, forward slashes (/), and other special characters (e.g., @, #, $, %).
    • Length Limits:
      • Tool Names: 1 to 64 characters.
      • Parameter Names: 1 to 64 characters (though keeping them $\le$ 32 characters is recommended for readability).
  3. Retrieve, Edit, and Assign Work Items

    main

    You can perform complex workflows involving retrieving work item details, summarizing comments, updating fields, and assigning ownership.

    Retrieve and Summarize:

    Get work item 12345 and show me fields ID, Type, State, Repro Steps, Story Points, and Priority. Get all comments for the work item and summarize them for me.

    Update Fields:

    Polish the Repro Steps with more information and details. Then take that value and update the work item. Also update StoryPoints = 5 and State = Active.

    Assign and Comment:

    Assign this work item to myemail@outlook.com and add a comment "I will own this Bug and get it fixed"
    Get work item 12345 and show me fields ID, Type, State, Repro Steps, Story Points, and Priority. Get all comments for the work item and summarize them for me.
    Polish the Repro Steps with more information and details. Then take that value and update the work item. Also update StoryPoints = 5 and State = Active.
    Assign this work item to myemail@outlook.com and add a comment "I will own this Bug and get it fixed"
  4. Use nightly builds for the Local MCP Server

    main

    To access the latest features before they are released in the stable version, update your mcp.json configuration to use the @next tag for the @azure-devops/mcp package.

    {
      "inputs": [
        {
          "id": "ado_org",
          "type": "promptString",
          "description": "Azure DevOps organization name  (e.g. 'contoso')"
        }
      ],
      "servers": {
        "ado": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@azure-devops/mcp@next", "${input:ado_org}"]
        }
      }
    }
  5. Setting a default project for LLM context

    main
    The MCP Server currently requires fetching the project list so the LLM has context regarding project names and IDs. To avoid repetitive fetching and provide immediate context, you can manually set a default project name in your copilot-instructions.md file.
  6. Resolve OAuth login failures by using Azure CLI authentication

    main

    If strict tenant admin policies prevent the OAuth flow from working (resulting in an error message in the browser after login), fall back to the Azure CLI authentication method.

    1. Install Azure CLI and run az login.
    2. Update your .vscode/mcp.json to use the azcli authentication option.
    {
      "inputs": [
        {
          "id": "ado_org",
          "type": "promptString",
          "description": "Azure DevOps organization name (e.g. 'contoso')"
        }
      ],
      "servers": {
        "ado": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@azure-devops/mcp", "${input:ado_org}", "--authentication", "azcli"]
        }
      }
    }
  7. Configure Azure DevOps MCP Server for Codex

    main

    Codex uses ~/.codex/config.toml for configuration. You can add the server via the CLI or by editing the config file directly.

    Interactive (Default):

    codex mcp add azure-devops -- npx -y @azure-devops/mcp Contoso

    Azure CLI Authentication: If you are already signed in via Azure CLI:

    az login
    codex mcp add azure-devops -- npx -y @azure-devops/mcp Contoso --authentication azcli

    Manual Configuration: Edit ~/.codex/config.toml:

    [mcp_servers.azure-devops]
    command = "npx"
    args = ["-y", "@azure-devops/mcp", "Contoso"]
  8. Authenticate using a Personal Access Token (PAT) via environment variables

    main

    For automated scenarios or when you want to use a token stored in an environment variable, use the envvar authentication type. This is the recommended method for headless environments (WSL2, SSH, Docker, CI runners).

    1. Set the ADO_MCP_AUTH_TOKEN environment variable with your PAT:
      export ADO_MCP_AUTH_TOKEN="your-azure-devops-token"
    2. Use the --authentication envvar flag when running the server via npx or update your .vscode/mcp.json as shown below.
    {
      "inputs": [
        {
          "id": "ado_org",
          "type": "promptString",
          "description": "Azure DevOps organization name (e.g. 'contoso')"
        }
      ],
      "servers": {
        "ado": {
          "type": "stdio",
          "command": "npx",
          "args": ["-y", "@azure-devops/mcp", "${input:ado_org}", "--authentication", "envvar"]
        }
      }
    }
  9. Triage Work Items using Iterations and Backlogs

    main

    To triage work effectively, first retrieve the team's iterations and backlog levels to provide context to the LLM.

    1. List context:
    list iterations for Contoso team
    list backlog levels for Contoso team
    1. Execute triage: Instruct the model to identify specific types of work (e.g., security bugs) and assign them to iterations:
    List of work items for Stories backlog. But then go thru and find all the security related bugs. Assign the first 4 to the current iteration. If there are more than four, assign the rest to the next iteration. Then find 2-3 high priority user stories and assign them to the current iteration. Do it!
    list iterations for Contoso team
    list backlog levels for Contoso team
    List of work items for Stories backlog. But then go thru and find all the security related bugs. Assign the first 4 to the current iteration. If there are more than four, assign the rest to the next iteration. Then find 2-3 high priority user stories and assign them to the current iteration. Do it!
  10. Add Artifact Links to Work Items

    main

    Associate work items with repository artifacts like branches, commits, or pull requests. You can either provide the full vstfs URI or provide the identifiers directly for the tool to construct the URI.

    Using full URIs:

    • Branch: vstfs:///Git/Ref/{projectId}%2F{repositoryId}%2FGB{branchName}
    • Commit: vstfs:///Git/Commit/{projectId}%2F{repositoryId}%2F{commitId}
    • Pull Request: vstfs:///Git/PullRequestId/{projectId}%2F{repositoryId}%2F{pullRequestId}

    Using identifiers (Automatic construction):

    Get me the list of pull requests for Constoso project and Frabrikam repo. Then link the first pull request to work item 12345.

    Manual URI example:

    Add a branch artifact link to work item 1234 in project "Contoso" with URI "vstfs:///Git/Ref/12341234-1234-1234-1234-123412341234%2F12341234-1234-1234-1234-123412341234%2FGBmain" and link type "Branch" with comment "Linked to main branch for GitHub Copilot integration"
    Get me the list of pull requests for Constoso project and Frabrikam repo. Then link the first pull request to work item 12345.
    Add a branch artifact link to work item 1234 in project "Contoso" with URI "vstfs:///Git/Ref/12341234-1234-1234-1234-123412341234%2F12341234-1234-1234-1234-123412341234%2FGBmain" and link type "Branch" with comment "Linked to main branch for GitHub Copilot integration"