---
title: "Connect Azure DevOps to Claude: Track PRs and Reviewer Feedback"
slug: connect-azure-devops-to-claude-track-prs-and-reviewer-feedback
date: 2026-11-04
author: Riya Sethi
categories: ["AI & Agents"]
excerpt: "Learn how to connect Azure DevOps to Claude using Truto's managed MCP server. Track pull requests, audit reviewer feedback, and ensure policy compliance."
tldr: "Connect Azure DevOps to Claude via a managed MCP server to track PRs, audit reviewer feedback, and enforce branch policies without writing custom integration code."
canonical: https://truto.one/blog/connect-azure-devops-to-claude-track-prs-and-reviewer-feedback/
---

# Connect Azure DevOps to Claude: Track PRs and Reviewer Feedback


If you need to connect Azure DevOps to Claude to track pull requests, audit reviewer feedback, or monitor branch policy compliance, you need a [Model Context Protocol (MCP) server](https://truto.one/what-is-mcp-and-mcp-servers-and-how-do-they-work/). This server acts as the translation layer between Claude's tool calls and the Azure DevOps REST API. You can either [build and maintain this infrastructure yourself](https://truto.one/how-to-build-a-custom-mcp-server-for-claude-to-access-saas-apis/), or use a [managed integration platform](https://truto.one/managed-mcp-for-claude-full-saas-api-access-without-security-headaches/) like Truto to dynamically generate a secure, authenticated MCP server URL. If your team uses ChatGPT, check out our guide on [/connect-azure-devops-to-chatgpt-audit-prs-and-branch-policies/](https://truto.one/connect-azure-devops-to-chatgpt-audit-prs-and-branch-policies/) or explore our broader architectural overview on [/connect-azure-devops-to-ai-agents-manage-prs-and-policy-compliance/](https://truto.one/connect-azure-devops-to-ai-agents-manage-prs-and-policy-compliance/).

Giving a Large Language Model (LLM) read and write access to a complex software development ecosystem like Azure DevOps is an engineering challenge. You have to handle OAuth 2.0 or Personal Access Token (PAT) lifecycles, map massive JSON schemas to MCP tool definitions, and deal with strict API versioning requirements. Every time Azure DevOps updates an endpoint, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Azure DevOps, connect it natively to Claude Desktop, and execute complex workflows using natural language.

> Want to give your AI agents secure, authenticated access to Azure DevOps and 100+ other SaaS APIs? Let's talk about [managed MCP architecture](https://truto.one/managed-mcp-for-claude-full-saas-api-access-without-security-headaches/).
>
> [Talk to us](https://truto.one/book-a-demo/)

## The Engineering Reality of the Azure DevOps API

A [custom MCP server](https://truto.one/how-to-build-a-custom-mcp-server-for-claude-to-access-saas-apis/) is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specialized enterprise APIs is painful. Azure DevOps is built to manage massive mono-repos, complex CI/CD pipelines, and strict organizational security boundaries. Its API reflects that complexity.

If you decide to build a custom Azure DevOps MCP server, here are the specific integration challenges you will face:

**Fragmented API Versioning**
Azure DevOps enforces strict API versioning at the endpoint level via the `api-version` query parameter (e.g., `api-version=7.1-preview.1`). Different resources stabilize at different times. Pull requests might use version 7.1, while branch policies might still rely on version 7.0. An LLM has no context on which API version to append to which URL. You must build an abstraction layer that presents a unified set of operations to Claude, hiding the underlying endpoint fragmentation and dynamically injecting the correct version strings.

**Complex Reviewer Voting Enums**
When you query pull request reviewers in Azure DevOps, the API does not return a simple boolean for "approved" or "rejected." Instead, it returns an integer-based vote. The values are specifically mapped: `10` (approved), `5` (approved with suggestions), `0` (no vote), `-5` (waiting for author), and `-10` (rejected). Exposing this raw endpoint to Claude often results in hallucinations, as the model attempts to guess what a `-5` vote means. A well-designed MCP server must include highly descriptive JSON schemas that explicitly map these integers to their human-readable definitions so the model can accurately interpret review states.

**Handling API Rate Limits**
Azure DevOps heavily throttles automated requests, especially for list operations across large repositories. It is critical to understand that Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream Azure DevOps API returns an HTTP 429 Too Many Requests error, Truto passes that exact error directly to the caller. Truto normalizes the upstream rate limit information into standardized headers (`ratelimit-limit`, `ratelimit-remaining`, `ratelimit-reset`) per the IETF specification. The caller - whether that is your custom agentic script or the LLM orchestration framework - is entirely responsible for reading these headers and implementing retry logic and backoff delays.

## Generating the Azure DevOps MCP Server

Truto abstracts away the complexity of the Azure DevOps API by dynamically generating MCP tools based on real-time documentation and API schemas. 

Each MCP server in Truto is scoped to a single authenticated tenant (an "integrated account"). The server URL contains a cryptographic token that securely authenticates requests and routes them to the correct Azure DevOps organization. 

You can generate this server URL using either the Truto UI or the REST API.

### Method 1: Via the Truto UI

For teams who want to manually connect an agent to an internal Azure DevOps instance, the UI provides a zero-code path:

1. Log into the Truto dashboard and navigate to the integrated account page for your Azure DevOps connection.
2. Click the **MCP Servers** tab.
3. Click **Create MCP Server**.
4. Select your desired configuration. You can optionally restrict the server to specific operations (e.g., `read` only) or specific tags (e.g., `pull_requests`).
5. Click Generate and copy the resulting MCP server URL (e.g., `https://api.truto.one/mcp/a1b2c3d4...`).

### Method 2: Via the Truto API

For developers building multi-tenant AI applications, you need to provision MCP servers dynamically via code. You can do this by making a `POST` request to the Truto API.

```bash
curl -X POST https://api.truto.one/integrated-account/{integrated_account_id}/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "DevOps PR Tracker",
    "config": {
      "methods": ["read"],
      "tags": ["pull_requests", "policies"]
    }
  }'
```

The API returns a fully configured MCP server URL ready for your agent to use:

```json
{
  "id": "b3c4d5e6",
  "name": "DevOps PR Tracker",
  "config": { "methods": ["read"], "tags": ["pull_requests", "policies"] },
  "expires_at": null,
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}
```

## Connecting the MCP Server to Claude

Once you have your Truto MCP server URL, you must register it with your Claude client. Because Truto MCP servers use Server-Sent Events (SSE) over HTTP, they do not require local binaries or Docker containers to run.

### Method 1: Via the Claude Desktop UI (and similar clients)

If you are using a modern client that supports custom remote connectors (like the enterprise tiers of Claude or ChatGPT Developer Mode):

1. Open your client settings.
2. Navigate to **Integrations** or **Connectors**.
3. Click **Add MCP Server** (or Add Custom Connector).
4. Paste your Truto MCP server URL (`https://api.truto.one/mcp/...`) and click **Add**.
5. The client will immediately perform the MCP handshake, discover the Azure DevOps tools, and make them available in the chat interface.

### Method 2: Via the Claude Desktop Configuration File

If you are using the standard Claude Desktop app for Mac or Windows, you can connect the remote Truto server using the official MCP SSE transport adapter. 

Edit your `claude_desktop_config.json` file (located at `~/Library/Application Support/Claude/claude_desktop_config.json` on macOS):

```json
{
  "mcpServers": {
    "azure_devops_truto": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}
```

Restart Claude Desktop. The app will use the SSE adapter to connect to the remote Truto endpoint, fetching all available Azure DevOps tools automatically.

## Hero Tools for Azure DevOps

Truto automatically maps Azure DevOps endpoints into descriptive, snake_case tools with highly enriched JSON schemas. This ensures the LLM knows exactly what parameters are required and what constraints exist. 

Here are the critical tools for managing PRs and policies.

### list_all_azure_dev_ops_pull_requests

This tool retrieves a list of pull requests within a specific Git repository. By default, it returns only active PRs. To fetch closed, completed, or abandoned PRs, the agent must pass `searchCriteria.status=all`.

Contextual usage note: Because this tool supports pagination, the schema explicitly instructs the LLM on how to pass the `limit` and `next_cursor` values back exactly as received.

> "Get all active pull requests in the 'core-backend' repository for the 'platform-engineering' project."

### get_single_azure_dev_ops_pull_request_by_id

This tool fetches the complete details of a specific pull request by its integer ID. It returns deep metadata, including the source branch, target branch, merge status, and creation date.

Contextual usage note: The agent must provide both the project name and the PR ID. The tool handles the complex route construction internally.

> "Fetch the details for PR #4092 in the 'infrastructure' project and tell me what branches it is attempting to merge."

### list_all_azure_dev_ops_pull_request_reviewers

This tool lists all assigned reviewers on a specific pull request, along with their current vote status. The schema explicitly maps the integer vote values (10, 5, 0, -5, -10) to their corresponding human-readable states, preventing the LLM from hallucinating the meaning of a `-5` vote.

Contextual usage note: This is essential for workflows that require nudging developers or auditing PR bottlenecks.

> "Check the reviewers for PR #4092. Are there any reviewers who are 'waiting for author' or who have rejected it?"

### list_all_azure_dev_ops_policy_configurations

This tool retrieves all branch policy configurations for a given project. In Azure DevOps, policies dictate rules like minimum required reviewers, successful build validation, and comment resolution mandates.

Contextual usage note: The API returns heavily nested configuration objects. Truto ensures the LLM receives these correctly structured so it can determine which branches are protected.

> "List all branch policies for the 'frontend-web' project. Are there any policies enforcing build validation on the main branch?"

### get_single_azure_dev_ops_policy_configuration_by_id

This tool fetches the exact settings of a single policy configuration by its ID. It reveals the exact threshold settings, such as whether self-approval is allowed or exactly how many reviewers are mandated.

Contextual usage note: The agent will typically discover the configuration ID using the list tool before calling this tool to audit specific compliance settings.

> "Get the details for policy configuration ID #15. Does this policy allow users to approve their own changes?"

To view the complete inventory of available operations and their exact schemas, visit the [Azure DevOps integration page](https://truto.one/integrations/detail/azuredevops).

## Workflows in Action

With the MCP server connected to Claude, you can string together multiple tool calls to accomplish complex DevOps tasks using natural language. Here are practical examples of how different personas use these tools.

### Scenario 1: Unblocking the PR Pipeline (Engineering Manager)

An engineering manager notices that a critical feature branch is delayed and asks Claude to investigate the hold-up.

> "Find out why the active PRs in the 'auth-service' repo are blocked. Check the reviewers for any PRs that are not fully approved and tell me who to ping."

**Step-by-step execution:**
1. Claude calls `list_all_azure_dev_ops_pull_requests` passing the `auth-service` repo name to get all active PRs.
2. Claude extracts the PR IDs from the response (e.g., PR #104 and PR #105).
3. Claude iterates through the PRs, calling `list_all_azure_dev_ops_pull_request_reviewers` for each one.
4. Claude analyzes the returned vote integers. It sees a `10` (approved) for PR #104, but a `-5` (waiting for author) from "Sarah Smith" on PR #105.

The manager gets a clear summary: "PR #105 is currently blocked. Sarah Smith marked it as 'waiting for author'. You should ping her or the PR author to resolve the pending comments."

```mermaid
sequenceDiagram
    participant EM as Eng Manager
    participant Claude as Claude (Agent)
    participant ADO as Azure DevOps API
    EM->>Claude: "Why are PRs blocked in auth-service?"
    Claude->>ADO: list_all_azure_dev_ops_pull_requests(repo: "auth-service")
    ADO-->>Claude: Returns PR #105
    Claude->>ADO: list_all_azure_dev_ops_pull_request_reviewers(pr: 105)
    ADO-->>Claude: Returns { reviewer: "Sarah Smith", vote: -5 }
    Claude-->>EM: "Sarah Smith is waiting on the author for PR #105."
```

### Scenario 2: Compliance Auditing for Branch Policies (DevSecOps)

A DevSecOps engineer needs to ensure that a newly created project adheres to strict SOC 2 compliance requirements regarding code review.

> "Check the branch policies for the 'payment-gateway' project. Ensure that there is a policy requiring at least two reviewers and that self-approval is disabled."

**Step-by-step execution:**
1. Claude calls `list_all_azure_dev_ops_policy_configurations` for the `payment-gateway` project.
2. Claude parses the list to find policies of type 'Minimum number of reviewers'.
3. Claude extracts the configuration ID for that specific policy.
4. Claude calls `get_single_azure_dev_ops_policy_configuration_by_id` using the extracted ID.
5. Claude reads the `settings` object in the response to verify `minimumApproverCount` is 2 and `allowDownvotes` or `creatorVoteCounts` logic is securely configured.

The engineer receives a definitive answer: "The 'payment-gateway' project is compliant. Policy ID 45 requires exactly 2 reviewers, and the setting allowing the creator to approve their own PR is explicitly set to false."

## Security and Access Control

When connecting an AI agent to a sensitive environment like Azure DevOps, security is paramount. Exposing tools that can approve PRs or modify policies indiscriminately is a major risk. Truto provides strict configuration boundaries applied at the infrastructure layer, ensuring the LLM cannot bypass them.

*   **Method Filtering:** When generating the server, you can restrict the token to `read` operations only. This ensures the LLM can only execute `get` and `list` tools. Any attempt to use `create`, `update`, or `delete` tools will be rejected before reaching Azure DevOps.
*   **Tag Filtering:** You can scope the MCP server down to specific resource tags. For example, if you set `tags: ["pull_requests"]`, the server will entirely omit tools related to users, policies, or repositories, keeping the agent hyper-focused.
*   **Time-To-Live (Expires At):** You can set an `expires_at` timestamp when creating the server. Once the timestamp passes, the server URL automatically expires, and all KV entries and cleanup alarms immediately purge the token. This is perfect for granting temporary audit access to an external contractor.
*   **Secondary Authentication (`require_api_token_auth`):** By default, possessing the MCP URL is enough to connect. For environments where the URL might leak in logs, you can enable `require_api_token_auth`. This forces the Claude client (or developer) to also pass a valid Truto API token in the connection headers, adding a rigorous second layer of identity verification.

## Wrapping Up

Connecting Claude to Azure DevOps via MCP transforms how engineering teams manage code reviews and compliance audits. By utilizing Truto to handle the OAuth/PAT connectivity, API version fragmentation, and complex JSON schema definitions, you can immediately begin executing complex, multi-step DevOps workflows via natural language.

Stop writing custom Python scripts to parse Azure DevOps reviewer votes. Generate a managed MCP server, connect it to your LLM, and let the agent do the heavy lifting.

> Ready to orchestrate Azure DevOps and 100+ other SaaS APIs with Claude? Let's discuss your AI integration architecture.
>
> [Talk to us](https://truto.one/book-a-demo/)
