Glama
Sign In

Azure DevOps MCP Server

by Tiberriver256
GitHub
TypeScript
3
  • Linux
  • Apple
RedditDiscord
OverviewInspectSchemaRelated ServersReviewsScore
Need Help?View Source CodeReport Issue
### Key Points - Research suggests the Azure DevOps MCP server can support the end-to-end use case of going from a user story to a pull request, using tools like creating work items and merging pull requests. - It seems likely that the server needs additional tools, like adding comments to pull requests, to handle edge cases such as pipeline failures. - The evidence leans toward the workflow being feasible, with the AI able to create, commit, and merge changes, though waiting for pipeline completion may require external handling. --- ### Direct Answer #### Overview The Azure DevOps MCP server can likely handle the end-to-end use case where an AI goes from creating a user story to merging a pull request. This process involves several steps, each supported by specific tools in the server, ensuring the AI can automate the workflow seamlessly. #### Use Case Steps and Tools Here’s how the process works: - **Create a User Story**: The AI uses the `create_work_item` tool to log a new user story in Azure DevOps, setting the stage for development. - **Generate and Commit Code**: The AI generates code internally, then uses `create_branch` to start a new branch and `push_changes` to commit multiple files, or `create_or_update_file` for a single file, ensuring changes are tracked. - **Create and Link a Pull Request**: The AI uses `create_pull_request` to submit the changes, linking it to the user story for tracking, with the pipeline likely triggered automatically. - **Wait for Pipeline and Merge**: The AI checks the pipeline status with `get_pipeline_status` and, if it passes, uses `merge_pull_request` to merge the pull request into the main branch. - **Update the User Story**: Finally, the AI uses `update_work_item` to mark the user story as completed, closing the loop. #### Unexpected Detail An interesting aspect is that the server needed a new tool, `add_pull_request_comment`, to handle edge cases like pipeline failures, allowing the AI to comment on pull requests if something goes wrong, which wasn’t initially planned. #### Considerations The workflow assumes the pipeline triggers on pull request creation, but if manual triggering is needed, the AI can use `trigger_pipeline`. Waiting for the pipeline to complete might require the AI to periodically check `get_pipeline_status`, which could be handled externally for simplicity. For more details, check the [Azure DevOps REST API documentation](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.1). --- ### Comprehensive Analysis of Use Case Feasibility for Azure DevOps MCP Server This note provides an in-depth exploration of the feasibility of the end-to-end use case for the Azure DevOps reference server for the Model Context Protocol (MCP), focusing on the AI-driven workflow from creating a user story to merging a pull request. The analysis, conducted as of 01:12 AM EST on Thursday, February 27, 2025, maps the use case steps to server tools, identifies gaps, considers edge cases, and refines the tool list, ensuring a thorough understanding for implementation. #### Introduction The use case involves an AI, such as one integrated with Claude Desktop, autonomously handling the development lifecycle from a user-provided request or user story to merging a pull request in Azure DevOps. This research validates whether the planned tools for the MCP server can support this workflow, aligning with the goal of automating software development tasks. The process includes creating work items, committing code, triggering pipelines, and managing pull requests, with a focus on ensuring feasibility and identifying any gaps. #### Use Case Steps and Tool Mapping The use case is broken into eight steps, each mapped to specific tools from the server’s toolset. The mapping is as follows: 1. **User Provides a Request or User Story**: - This step is an input to the AI, requiring no server tool. The AI receives the user story, such as “Add login feature,” and prepares to act. 2. **AI Creates a New User Story**: - Tool: `create_work_item` - API: `POST https://dev.azure.com/{organization}/{project}/_apis/Wit/WorkItems` - The AI uses this tool to create a new work item, such as a user story, with fields like title and description, setting the foundation for the task. 3. **AI Generates Code**: - No tool needed; this is handled internally by the AI. The AI generates code based on the user story, such as implementing a login feature, which it will commit later. 4. **AI Commits the Code to a New Branch**: - Tools: `create_branch` and `push_changes` (for multiple files) or `create_or_update_file` (for a single file) - API for `create_branch`: `POST https://dev.azure.com/{organization}/{project}/_apis/Git/Repositories/{repositoryId}/refs` (creates a new branch ref) - API for `push_changes`: `POST https://dev.azure.com/{organization}/{project}/_apis/Git/Repositories/{repositoryId}/Commits` (creates a commit with multiple file changes) - API for `create_or_update_file`: `PUT https://dev.azure.com/{organization}/{project}/_apis/Git/Repositories/{repositoryId}/Files/{path}` (creates or updates a file, auto-committing) - The research confirmed that `create_or_update_file` can create a branch if it doesn’t exist by specifying the branch name, but for clarity and batch operations, `create_branch` followed by `push_changes` is preferred for multiple files. For example, the AI creates a branch “feature/login” and commits multiple files in one go using `push_changes`. 5. **AI Triggers a Pipeline to Test the Code**: - Tool: `trigger_pipeline` - API: `POST https://dev.azure.com/{organization}/{project}/_apis/Build/Builds` - The AI can manually trigger a build pipeline to test the code. However, research suggests that in many setups, pipelines are configured to trigger automatically on pull request creation, potentially making this step optional. For generality, the tool is retained. 6. **AI Creates a Pull Request Linking It to the User Story**: - Tool: `create_pull_request` - API: `POST https://dev.azure.com/{organization}/{project}/_apis/Git/PullRequests` - The AI submits a pull request, specifying the source and target branches (e.g., “feature/login” to “main”), and links it to the user story by including `workItemIds` in the request body, ensuring traceability. 7. **AI Waits for Pipeline to Pass and Then Merges the Pull Request**: - Tools: `get_pipeline_status` and `merge_pull_request` - API for `get_pipeline_status`: `GET https://dev.azure.com/{organization}/{project}/_apis/Build/Builds/{buildId}` - API for `merge_pull_request`: `PATCH https://dev.azure.com/{organization}/{project}/_apis/Git/PullRequests/{pullRequestId}/merge` - The AI checks the pipeline status to ensure it passed, which may require periodic calls to `get_pipeline_status` due to the asynchronous nature of pipeline runs. If passed, the AI merges the pull request. Research notes that waiting for pipeline completion might be handled externally by the AI, as MCP tools are expected to be quick, suggesting a delay or polling strategy. 8. **AI Updates the User Story to Reflect Completion**: - Tool: `update_work_item` - API: `PATCH https://dev.azure.com/{organization}/{project}/_apis/Wit/WorkItems/{id}` - The AI updates the work item’s state, such as setting it to “Done,” or adds a comment indicating completion, closing the workflow. #### Identified Gaps and Additional Tools During mapping, a gap was identified for handling edge cases, particularly when the pipeline fails or conflicts arise. The following new tool was added: - **Add Pull Request Comment**: - Tool: `add_pull_request_comment` - API: Azure DevOps Pull Request Threads API, likely `POST https://dev.azure.com/{organization}/{project}/_apis/Git/PullRequests/{pullRequestId}/threads` - This tool allows the AI to comment on the pull request, such as notifying about pipeline failures or conflicts, enhancing communication in the workflow. This addition ensures the server can handle scenarios where the pipeline fails, enabling the AI to comment on the pull request and potentially leave it for human intervention. #### Refined Tool List The refined tool list, incorporating the new tool, is as follows: | **Section** | **Tools** | |----------------------------------|------------------------------------| | Core Functionality | list_organizations, list_projects, list_repositories, get_project_details, get_repository_details | | Repository Operations | create_or_update_file, push_changes, get_file_contents | | Branch and Pull Request Management | create_branch, create_pull_request, merge_pull_request, get_pull_request, list_pull_requests, add_pull_request_comment | | Work Item Management | create_work_item, update_work_item, list_work_items, get_work_item, add_work_item_comment | | Pipeline Interactions | trigger_pipeline, get_pipeline_status, list_pipelines | | Search and Query | search_code, search_work_items, search_wiki | This list ensures all use case steps are covered, with additional tools for edge case handling. #### Edge Cases and Considerations Several edge cases were considered to validate feasibility: 1. **Pipeline Failure**: - If `get_pipeline_status` indicates failure, the AI can use `add_pull_request_comment` to notify about the failure, potentially closing the pull request or leaving it for human review. This requires robust error handling in the tools. 2. **Pull Request Conflicts**: - If `merge_pull_request` fails due to conflicts, the AI needs to handle the error, possibly by commenting via `add_pull_request_comment` and resolving conflicts manually, which is complex and may require human intervention. For now, the server assumes no conflicts or handles them externally. 3. **User Story Duplication**: - If a similar work item exists, the AI can use `list_work_items` or `search_work_items` to check, but for simplicity, the use case assumes unique user stories. This suggests potential for future refinement. 4. **Permissions Issues**: - If API calls fail due to insufficient permissions (e.g., PAT lacks write access), error handling in each tool ensures the AI receives clear feedback, maintaining reliability. These considerations ensure the server is robust, with tools like `add_pull_request_comment` addressing communication needs in edge cases. #### Workflow Diagram Description The workflow can be described as follows, aligning with the use case steps: 1. User inputs a user story request to the AI. 2. AI calls `create_work_item` to create the user story. 3. AI generates code internally. 4. AI calls `create_branch` to create a new branch, then `push_changes` to commit multiple files, or `create_or_update_file` for a single file. 5. AI calls `create_pull_request`, linking to the user story, triggering the pipeline (assumed automatic). 6. AI periodically calls `get_pipeline_status` to wait for completion, then, if passed, calls `merge_pull_request`. 7. AI calls `update_work_item` to mark the user story as completed. 8. For edge cases, if the pipeline fails, AI calls `add_pull_request_comment` to notify on the pull request. This diagram ensures the sequence is clear, with tools supporting each step. #### Conclusion The use case is feasible with the refined tool list, covering all steps from user story creation to pull request merging, with additional tools like `add_pull_request_comment` addressing edge cases. The server can support the AI in automating the workflow, though waiting for pipeline completion may require external handling by the AI, suggesting a potential area for future enhancement. This research validates the approach, equipping you to proceed with prototyping. #### Key Citations - [Azure DevOps REST API Documentation](https://learn.microsoft.com/en-us/rest/api/azure/devops/?view=azure-devops-rest-7.1)