Azure DevOps MCP vs GitLab MCP Server

Azure DevOps MCP Server

[!IMPORTANT]
We recommend using the Remote MCP Server instead of this local server. It requires no installation and gets new features first.

Learn more

This project gives AI agents access to Azure DevOps through the Model Context Protocol (MCP). Use the hosted remote server for the simplest setup, or run the local server when you need a stdio connection.

Table of Contents

1. Overview
2. Design
3. Remote MCP Server (Recommended)
4. Supported Tools
5. Local MCP Server Installation (Optional)
6. Using Domains (Local Server)
7. Project and Team Defaults (Local Server)
8. Troubleshooting
9. Examples and Best Practices
10. Frequently Asked Questions
11. Contributing

Overview

The Azure DevOps MCP Server brings Azure DevOps context to your agents. Try prompts like:

• "List my ADO projects"
• "List ADO Builds for 'Contoso'"
• "List ADO Repos for 'Contoso'"
• "List test plans for 'Contoso'"
• "List teams for project 'Contoso'"
• "List iterations for project 'Contoso'"
• "List my work items for project 'Contoso'"
• "List work items in current iteration for 'Contoso' project and 'Contoso Team'"
• "List all wikis in the 'Contoso' project"
• "Create a wiki page '/Architecture/Overview' with content about system design"
• "Update the wiki page '/Getting Started' with new onboarding instructions"
• "Get the content of the wiki page '/API/Authentication' from the Documentation wiki"

Design

Each tool handles a focused Azure DevOps task. The server provides a thin layer over the REST APIs, while the AI agent handles higher-level reasoning.

Remote MCP Server (Recommended)

For complete instructions, see the Remote MCP Server onboarding documentation.

The remote server will eventually replace the local server. The local server remains supported, but new development will focus on the remote server. Existing local server users should begin planning their migration.

If you encounter issues with tools, need support, or have a feature request, you can report an issue using the Remote MCP Server issue template. During the preview period, we will track Remote MCP Server issues through this repository.

Quick Start

Create .vscode/mcp.json in your project and add this configuration. Replace {organization} with your Azure DevOps organization name.

{
  "servers": {
    "ado-remote-mcp": {
      "url": "https://mcp.dev.azure.com/{organization}",
      "type": "http"
    }
  },
  "inputs": []
}

See the remote server configuration documentation for more options.

After saving .vscode/mcp.json, start the server from the MCP view in VS Code, then run a prompt like List ADO projects.

Supported Tools

See the Available Tools documentation for the complete list of available remote tools.

For the complete list of local tools, see TOOLSET.md.

Local MCP Server Installation (Optional)

[!IMPORTANT]
Start with the Remote MCP Server first. Use the local MCP Server only if your scenario specifically requires a local stdio setup.

These steps use Visual Studio Code and GitHub Copilot. For other supported clients, including Visual Studio 2022, Codex, Claude Code, Cursor, OpenCode, and Kilo Code, see the getting started guide.

Prerequisites

1. Install VS Code or VS Code Insiders.
2. Install Node.js 20 or later.
3. Open your project in VS Code.

Installation

Install from npm

1. Create .vscode/mcp.json in your project.
2. Add this configuration:

{
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "{organization}"]
    }
  }
}

3. Save the file, then start the ado server from the MCP view in VS Code.
4. Open GitHub Copilot Chat and switch to Agent mode.
5. Select the Azure DevOps tools, then try a prompt such as List ADO projects.
6. When prompted, sign in with a Microsoft account that has access to the selected Azure DevOps organization.

To use nightly builds, replace @azure-devops/mcp with @azure-devops/mcp@next in the configuration.

For better tool selection, add .github/copilot-instructions.md to your project with this instruction:

This project uses Azure DevOps. Always check whether the Azure DevOps MCP server has a tool relevant to the user's request.

Using Domains (Local Server)

The local server includes many tools. Domains let you load only the tool groups you need, which keeps the tool list manageable and helps clients with tool limits. Available domains are core, work, work-items, search, test-plans, repositories, wiki, pipelines, and advanced-security.

Add -d followed by the domains to the server arguments. For example, this configuration loads only work item-related tools:

{
  "servers": {
    "ado_with_filtered_domains": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "{organization}", "-d", "core", "work", "work-items"]
    }
  }
}

Always include core so the agent can retrieve project information.

If you omit -d, the server loads all domains.

Project and Team Defaults (Local Server)

Set default Azure DevOps project and team values in .vscode/mcp.json so tools can skip selection prompts.

Example .vscode/mcp.json

{
  "servers": {
    "ado": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@azure-devops/mcp", "{organization}", "--authentication", "azcli"],
      "env": {
        "ado_mcp_project": "Contoso",
        "ado_mcp_team": "Fabrikam Team"
      }
    }
  }
}

Troubleshooting

See the Troubleshooting guide for help with common issues and logging.

Examples

See the examples for sample prompts.

Frequently Asked Questions

For answers to common questions about the Azure DevOps MCP Server, see the Frequently Asked Questions.

Contributing

We welcome contributions. During preview, file issues for bugs, enhancements, or documentation improvements.

See our Contributions Guide for:

• Development setup
• Adding new tools
• Code style and testing
• Pull request process

Read the Contributions Guide before creating a pull request.

Code of Conduct

This project follows the Microsoft Open Source Code of Conduct.
For questions, see the FAQ or contact open@microsoft.com.

Hall of Fame

Thanks to all contributors who make this project awesome! ❤️

Generated with contrib.rocks

License

Licensed under the MIT License.

Trademarks: This project may include trademarks or logos for Microsoft or third parties. Use of Microsoft trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Third-party trademarks are subject to their respective policies.

Overview

The GitLab MCP server is GitLab's official Model Context Protocol endpoint. It lets MCP-compatible clients — Claude Desktop, Claude Code, Cursor and others — securely read GitLab project data and perform actions on your behalf through a standard interface instead of a custom integration.

It is generally available and included with GitLab Free, Premium and Ultimate on GitLab.com, GitLab Self-Managed and GitLab Dedicated. The server is served by your GitLab instance at /api/v4/mcp.

Core capabilities

• Project and repository access — read project metadata, files and repository information.
• Issues and merge requests — retrieve issue and MR data, and perform GitLab-specific operations through the AI client.
• Work items — interact with GitLab work items through dedicated tools.
• CI tools — inspect pipelines and CI-related data.
• GitLab Duo Agent Platform — tools that let an agent propose and start Duo flows, with confirmation before execution.
• Wikis, code security and Orbit — opt-in toolsets for wiki pages, vulnerability management (Ultimate) and the Orbit knowledge graph.
• OAuth 2.0 Dynamic Client Registration — an MCP client can register itself as an OAuth application, request authorization and receive an access token on first connect.
• Toolset selection — limit exposed tools with the X-Gitlab-Enabled-Mcp-Server-Toolsets header; use all for everything.
• Tool name prefixing — avoid collisions with X-Gitlab-Mcp-Server-Tool-Name-Prefix.
• Audit events — optionally record an AI audit event for each MCP tool call.

Authentication

The server accepts an OAuth access token with the mcp scope (obtained through the OAuth flow) or a fine-grained personal access token with the MCP tool resource and Execute permission. Legacy personal access tokens, project access tokens and group access tokens cannot get the mcp scope and are rejected with 403 insufficient_scope.

Transports and protocol

• HTTP transport (recommended) — point the client at https://<your-gitlab-host>/api/v4/mcp.
• stdio via mcp-remote — for clients that only speak stdio; requires Node.js.
• Supported protocol versions: 2025-11-25, 2025-06-18 and 2025-03-26; 2026-07-28 is accepted in initialize but answered with 2025-11-25.

Rate limits

Per-user limits: Free 60 requests/minute and 3,600/hour; Premium and Ultimate 600/minute and 5,000/hour. Limits are shared across all clients and tokens for a user, and count toward GitLab.com's general rate limits. Exceeding them returns 429 with Retry-After and RateLimit-Reset.

Getting started

1. Allow MCP access for the top-level group on GitLab.com, or for the instance on Self-Managed/Dedicated.
2. Add the server to your client using the HTTP URL https://<host>/api/v4/mcp.
3. Complete the OAuth flow (or supply a fine-grained PAT with the MCP resource).
4. Optionally restrict toolsets with the X-Gitlab-Enabled-Mcp-Server-Toolsets header.
5. Ask the client to read a project, list issues or open a merge request.

Links

• Docs: docs.gitlab.com/user/model_context_protocol/mcp_server
• Tools reference: docs.gitlab.com/user/model_context_protocol/mcp_server_tools
• Troubleshooting: docs.gitlab.com/user/model_context_protocol/mcp_server_troubleshooting