MCP Azure DevOps Server
# MCP Azure DevOps Server
MCP server for Azure DevOps Git operations integration with AWS Q.
## Setup
1. Install dependencies:
```bash
npm install
```
2. Configure environment variables:
```bash
cp .env.example .env
# Edit .env with your Azure DevOps details
```
**📋 For detailed configuration steps, see [CONFIGURATION.md](./CONFIGURATION.md)**
3. Build and run:
```bash
npm run build
npm start
```
## Configuration for AWS Q
### Option 1: Use the provided config file
Copy `mcp_config.json` to your AWS Q MCP configuration directory.
### Option 2: Manual configuration
Add to your AWS Q MCP client configuration:
```json
{
"mcpServers": {
"azure-devops": {
"command": "node",
"args": ["c:/Users/somesh.rajasekar/Apps/mcp-azure-devops/dist/index.js"],
"env": {
"AZURE_DEVOPS_ORG_URL": "your-org-url",
"AZURE_DEVOPS_PAT": "your-pat-token"
}
}
}
}
```
### Usage in AWS Q
Once configured, use these commands in AWS Q chat:
- Search repositories: "Search for any repository"
- Get repository info: "Get repository info for any repo"
- Get pipeline variables: "Get pipeline variables for MyProject"
- Get variable groups: "Get variable groups for MyProject"
## Available Tools
### Repository Operations
- `search_repositories` - Search for repositories across all projects with branch info and latest PROD/QA deployments
- `get_repository_info` - Get repository URL, branches with latest check-in dates, and latest PROD/QA deployment information
### Pipeline Variables
- `get_pipeline_variables` - Get variables from build/release pipelines (supports filtering by pipeline name and type)
- `get_variable_groups` - Get variable groups from a project (supports filtering by group name)
TDQS
Scored across 4 tools
Repository-related tools and variable-related tools are clearly separated, and the descriptions clarify their scope. The only mild ambiguity is between get_pipeline_variables and get_variable_groups, but their descriptions differentiate pipeline-scoped variables from project-level variable groups.
All tool names follow a consistent get_/search_ + noun pattern, making the naming predictable and easy to navigate. There is no mixing of conventions or vague verbs.
Four tools is slightly thin for a server claiming Azure DevOps coverage, but each tool covers a distinct read-only concern. The count is acceptable for a focused utility server, though not richly scoped.
The server only covers limited read operations for repositories, pipeline variables, and variable groups. Major Azure DevOps areas like work items, build/release execution, pull requests, and commits are entirely absent, leaving significant gaps for common agent workflows.