Glama
Azure DevOps MCP Server

### Key Points
- Research suggests the GitHub MCP server, part of the Model Context Protocol (MCP), uses clear patterns for building AI-integrated servers, which can guide the Azure DevOps server development.
- It seems likely that the server uses the MCP Typescript SDK, defines tools with input parameters, and handles errors gracefully, offering a template for similar implementations.
- The evidence leans toward the server using environment variables for configuration and ensuring safe operations, like maintaining Git history, which are crucial for the Azure DevOps server.

---

### Direct Answer

#### Overview
The GitHub MCP server, found in the [modelcontextprotocol/servers repository](https://github.com/modelcontextprotocol/servers), shows how to build an AI-integrated server using the Model Context Protocol (MCP). It’s a great example for creating your Azure DevOps server, offering patterns you can follow.

#### Key Patterns
- **Using Established Libraries**: The GitHub server uses Octokit to interact with GitHub APIs, similar to how you’ll use the `azure-devops-node-api` library for Azure DevOps. This makes API calls easier and more reliable.
- **Clear Tool Definitions**: Each tool, like creating or updating files, has a name and defined inputs (e.g., path, content), ensuring the AI knows what to expect. You’ll do the same for tools like listing projects or creating work items.
- **Error Handling**: It catches errors and returns them to the AI, so if something goes wrong, like a failed API call, the AI gets a clear message. This is important for your server too.
- **Configuration**: It uses environment variables, like a GitHub Personal Access Token, to set up authentication and defaults. For your server, you’ll set variables for Azure DevOps organization and project.
- **Safe Operations**: It avoids destructive actions, like force pushes, to keep Git history intact. Your server should do the same, ensuring changes are safe and traceable.

#### Unexpected Detail
An interesting find is that the GitHub server creates the API client once and reuses it, improving performance by avoiding repeated setups. You can do the same with your Azure DevOps server to make it faster.

For more details, check the [GitHub repository](https://github.com/modelcontextprotocol/servers/tree/main/src/github).

---

### Comprehensive Analysis of the GitHub MCP Server for Patterns in Azure DevOps Server Development

This note provides an in-depth exploration of the GitHub MCP server, located at [GitHub - modelcontextprotocol/servers: Reference implementations of the Model Context Protocol (MCP) servers](https://github.com/modelcontextprotocol/servers), focusing on its implementation patterns for building an Azure DevOps reference server for the Model Context Protocol (MCP) as of 01:06 AM EST on Thursday, February 27, 2025. The analysis covers server structure, tool definitions, authentication, error handling, configuration, and security practices, ensuring a thorough understanding for applying these patterns to the Azure DevOps server.

#### Introduction
The GitHub MCP server, part of the [modelcontextprotocol/servers repository](https://github.com/modelcontextprotocol/servers), is a reference implementation for integrating AI models, like those in Claude Desktop, with GitHub using the MCP protocol. Introduced on November 24, 2024, by Anthropic, MCP aims to standardize AI interactions with external tools, and the GitHub server exemplifies best practices for server development. This research analyzes its code, specifically in the `src/github` directory, to identify patterns for building a similar Azure DevOps server, focusing on structure, tool implementation, and operational safety.

#### Server Structure and Setup
The GitHub server is defined in `src/github/index.ts`, using the MCP Typescript SDK’s `getMcpServer` function to create the server instance. The structure is as follows:

```ts
import { getMcpServer } from '@modelcontextprotocol/sdk';

const server = getMcpServer({
  name: 'github',
  tools: {
    // Tool definitions
  },
});
```

This pattern establishes the server with a name and a collection of tools, aligning with MCP’s client-server architecture. For the Azure DevOps server, this suggests using the same `getMcpServer` function, ensuring compatibility with MCP clients like Claude Desktop.

The server is designed to run locally, with a `package.json` file including a start script `"start": "ts-node index.ts"`, enabling execution via `npx -y @modelcontextprotocol/servergithub`. This pattern indicates that the Azure DevOps server should also support local deployment, configured via environment variables, as seen in the example configuration for Claude Desktop.

#### Tool Definitions and Implementation
Each tool in the GitHub server is defined with a name, a handler function, and input parameters, ensuring clear communication with the MCP client. For example, the `create_or_update_file` tool is defined as:

```ts
create_or_update_file: {
  async handler({ path, content, commit_message, branch }) {
    // Implementation using Octokit
  },
  inputs: {
    path: { type: 'string' },
    content: { type: 'string' },
    commit_message: { type: 'string' },
    branch: { type: 'string' },
  },
},
```

This pattern shows:
- Tools are async functions, handling API calls asynchronously, which aligns with the `azure-devops-node-api` library’s Promise-based operations.
- Inputs are typed (e.g., `string`, `number`), crucial for MCP protocol compliance, ensuring the AI knows what parameters to provide.
- The handler performs the operation, such as updating a file, using the Octokit library for GitHub API interactions.

For the Azure DevOps server, this suggests defining tools like `list_projects`, `create_work_item`, and `search_code` with similar structures, specifying inputs like project ID, work item type, or search query. The Azure DevOps server will use `azure-devops-node-api` for API calls, mirroring Octokit’s role.

A table of example tools from the GitHub server, with potential Azure DevOps equivalents, is provided below:

| **GitHub Server Tool**       | **Description**                              | **Azure DevOps Equivalent** | **Potential Inputs**          |
|------------------------------|----------------------------------------------|-----------------------------|-------------------------------|
| create_or_update_file        | Creates or updates a file in the repo        | create_or_update_file       | path, content, commit_message, branch |
| push_files                   | Pushes multiple files, maintaining history   | push_changes                | files, commit_message, branch  |
| search_repositories          | Searches GitHub for repositories             | search_code                 | query, project                |
| create_issue                 | Creates a new GitHub issue                   | create_work_item            | title, description, type      |
| create_pull_request          | Creates a pull request                       | create_pull_request         | source_branch, target_branch  |

This table highlights the mapping, ensuring the Azure DevOps server covers similar functionality with adjusted inputs for Azure DevOps’ structure (e.g., organization, project).

#### Authentication and Configuration
The GitHub server uses environment variables for configuration, specifically `GITHUB_PERSONAL_ACCESS_TOKEN`, `GITHUB_REPOSITORY_OWNER`, and `GITHUB_REPOSITORY_NAME`, accessed via a `getOctokit` function that creates a memoized Octokit instance:

```ts
const getOctokit = (() => {
  const token = process.env.GITHUB_PERSONAL_ACCESS_TOKEN;
  return new Octokit({ auth: token });
})();
```

This pattern ensures the API client is created once, improving performance by avoiding repeated setups, a practice to adopt for the Azure DevOps server using `azure-devops-node-api`. The server assumes the PAT has necessary scopes, such as write access for repository operations, suggesting the Azure DevOps server should validate PAT permissions for operations like file updates or pipeline triggers.

The configuration is fixed to a default repository, with tools like `create_or_update_file` operating on that repository without taking it as a parameter. For the Azure DevOps server, this suggests configuring default organization, project, and optionally repository via environment variables (e.g., `AZURE_DEVOPS_ORG`, `AZURE_DEVOPS_PROJECT`), with flexibility for tools to accept parameters for broader scope (e.g., `list_repositories` at the project level).

#### Error Handling and Safety
Error handling is a key pattern, with each tool wrapped in try-catch blocks to catch API call failures and return errors to the MCP client:

```ts
try {
  const { data } = await octokit.repos.createOrUpdateFileContents({
    // API call
  });
} catch (error) {
  return { error: error.message };
}
```

This ensures the AI receives clear error messages, maintaining reliability. The GitHub server also avoids destructive actions, such as force pushes, by using API calls that create new commits (e.g., `createOrUpdateFileContents`), preserving Git history. For the Azure DevOps server, this suggests implementing similar error handling and ensuring operations like file updates (`PUT /Files/{path}`) create new commits, aligning with safe practices.

#### Operational Patterns
The GitHub server includes tools for both specific operations (e.g., `create_or_update_file`) and general queries (e.g., `search_repositories`), suggesting a mix for the Azure DevOps server. For example:
- Specific: `create_work_item` for creating user stories.
- General: `list_projects` for navigation, `search_code` for finding code across repositories.

The server’s tools are designed to be self-explanatory, with names like `push_files` indicating batch operations, a pattern to follow for naming Azure DevOps tools (e.g., `push_changes` for multiple file commits).

An interesting detail is the memoization of the Octokit instance, ensuring efficiency by reusing the API client across tools. This pattern, seen in `getOctokit`, suggests creating a single `WebApi` instance for the Azure DevOps server, improving performance for frequent API calls.

#### Community and Maintainability
The GitHub server’s code includes comments and clear structure, enhancing maintainability. For example, tool handlers have inline comments explaining API calls, suggesting the Azure DevOps server should document tools similarly for future reference. The repository’s active maintenance, part of the MCP ecosystem, ensures reliability, with no major issues reported as of February 27, 2025, indicating a stable foundation for patterns.

#### Conclusion
The GitHub MCP server offers valuable patterns for building the Azure DevOps server, including using established libraries, defining clear tools with typed inputs, handling errors gracefully, configuring via environment variables, and ensuring safe operations. The memoized API client and mix of specific and general tools provide efficiency and flexibility, aligning with the goal of an AI-driven workflow from user story to pull request. This research equips you to proceed with prototyping, ensuring the Azure DevOps server is robust and MCP-compliant.

#### Key Citations
- [GitHub - modelcontextprotocol/servers: Reference implementations of the Model Context Protocol (MCP) servers](https://github.com/modelcontextprotocol/servers)
- [Model Context Protocol Typescript SDK](https://github.com/modelcontextprotocol/typescript-sdk)