Azure DevOps MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AZURE_DEVOPS_ORG | Yes | Your Azure DevOps organization name | |
| AZURE_DEVOPS_PAT | Yes | Your Personal Access Token with Work Items (Read & Write) scope | |
| AZURE_DEVOPS_PROJECT | Yes | Your Azure DevOps project name |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_work_itemB | Get a single work item by ID with all fields and relations |
| list_work_itemsC | List work items by type (Epic, Feature, User Story, Task, Bug) with filters |
| query_work_itemsB | Execute a WIQL query. Example: SELECT [System.Id] FROM WorkItems WHERE [System.WorkItemType] = 'Bug' AND [System.State] = 'Active' |
| get_child_work_itemsD | Get child work items of a parent |
| get_sprint_capacityC | Get team member capacity for a sprint (hours per day, days off) |
| list_repositoriesB | List all Git repositories in the project |
| get_repositoryC | Get details of a specific repository |
| list_saved_queriesC | List saved work item queries in the project |
| run_saved_queryB | Execute a saved work item query and return the matching work items |
| get_projectB | Get current project details |
| get_work_item_typesB | List available work item types |
| get_iterationsB | List iterations/sprints |
| get_iteration_work_itemsA | Get all work items for a specific iteration/sprint path. Faster than query_work_items for sprint planning. |
| list_work_item_fieldsB | List all available work item field names and their reference names (useful for custom queries) |
| list_tagsB | List all work item tags in the project |
| get_area_pathsC | List area paths |
| list_wikisB | List all wikis in the project |
| get_wikiC | Get details of a specific wiki |
| get_wiki_pageB | Get content of a wiki page by path |
| get_wiki_page_revisionsB | Get the revision/edit history of a wiki page (who changed it and when) |
| list_wiki_pagesB | List all pages in a wiki (table of contents) |
| get_work_item_updatesA | Get the full change history of a work item (who changed what and when) |
| get_teamsB | List all teams in the current project. Use team names with get_sprint_board. |
| list_work_item_relation_typesA | List all available work item relation/link types (use these values with link_work_items) |
| search_work_itemsA | Search work items by text across title, description and comments. Easier than WIQL for natural language queries. |
| get_work_item_commentsB | Get all comments/discussion history for a work item |
| get_sprint_boardB | Get the current sprint/iteration board with all work items assigned to it |
| get_current_userB | Get the current authenticated user identity (useful for knowing your user ID for voting on PRs, assigning work items, etc.) |
| get_current_configB | Get current Azure DevOps organization and project configuration |
| set_projectA | Switch to a different project within the current organization. Use list_projects first to see available projects. |
| get_work_item_typeB | Get detailed information about a work item type including its fields, states, and icon. |
| get_current_sprintB | Get the current active sprint/iteration for a team. Returns sprint name, dates, and path. |
| get_sprint_work_itemsC | Get all work items in a specific sprint iteration. |
| get_wiki_page_textA | Get the raw markdown/text content of a wiki page (without metadata). |
| get_current_user_permissionsA | Get the permission level and group memberships of the currently authenticated user. Returns whether the user is an org admin, project admin, contributor, or reader. Useful to understand what operations are allowed before attempting them. |
| get_user_profileA | Get profile information for an Azure DevOps user by their user ID or "me" for the authenticated user. |
| get_work_items_by_idsA | Fetch multiple work items by their IDs in a single request. More efficient than calling get_work_item repeatedly. |
| get_work_item_parentA | Get the parent work item of a given work item. Returns null if the work item has no parent. |
| get_team_membersC | List all members of a specific team. |
| list_dashboardsC | List team dashboards. Returns dashboard names and IDs. |
| get_work_item_attachmentsC | List all attachments on a work item (files, images, documents). |
| search_codeB | Search for code across all repositories in the project. Returns matching files with line context. |
| list_project_groupsB | List all security groups defined in the current project. |
| get_my_roleA | Get your current role in this MCP server. Shows detected role, source (Azure DevOps groups or env var), and what level of access you have. |
| get_work_item_type_statesB | List all workflow states for a given work item type (e.g. Bug, Task, User Story). Useful to know valid state transitions. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 45 tools
Most tools have distinct purposes with clear resource-action pairs, such as get_work_item, list_work_items, and query_work_items. However, some overlap exists, like get_sprint_work_items and get_iteration_work_items, which could cause confusion despite descriptive names. Overall, the set is well-differentiated with only minor ambiguities.
Tool names follow a highly consistent verb_noun pattern throughout, using verbs like get, list, search, set, and run. All names use snake_case uniformly, making them predictable and easy to parse. This consistency aids agent selection and reduces cognitive load.
With 45 tools, the count is high and may feel heavy for the Azure DevOps domain, potentially overwhelming agents. While the tools cover many aspects, some could be consolidated or omitted without losing functionality. It's borderline excessive but still manageable given the comprehensive scope.
The tool surface provides extensive coverage for Azure DevOps, including work items, repositories, wikis, sprints, queries, and user management. It supports full CRUD-like operations (e.g., get, list, query, search) across all major resources, with no obvious gaps that would hinder agent workflows in this domain.