[REMOTE] Support Azure DevOps Work Item Templates in Remote MCP Server

[Chris (cpAdm)]

Issue Type

• Tool or feature request for Remote MCP Server
• Feedback on Remote MCP Server
• Bug in Remote MCP Server

Tool(s)

Proposed new capability

Support Azure DevOps Work Item Templates within the Work Item (WIT) toolset.

Possible implementation options:

1. New tool: wit_get_work_item_templates

   • Retrieve available Azure DevOps work item templates for a team/project.
   • Return template metadata such as template name, work item type, description, and template identifier.

2. New tool: wit_create_work_item_from_template

   • Create a work item directly from an Azure DevOps work item template.
   • Allow optional field overrides.

Alternatively:

3. Enhance existing wit_create_work_item
   • Add a templateId or templateName parameter.
   • Apply template defaults before applying user-specified field values.

Description

The Azure DevOps MCP Server currently provides comprehensive work item creation and management capabilities through tools such as wit_create_work_item, wit_update_work_item, and related WIT operations. However, there is currently no way to discover or use Azure DevOps Work Item Templates when creating work items via MCP.

Many Azure DevOps teams use Work Item Templates to standardise required fields, default values, area paths, tags, priorities, acceptance criteria, and other metadata. When work items are created through MCP, agents must currently recreate this template logic manually, which can lead to inconsistencies and duplication of configuration.

Why this capability is needed

Work Item Templates are commonly used to enforce team standards and reduce repetitive data entry. AI agents and automation workflows should be able to leverage the same templates that are available to users in the Azure DevOps web experience.

Without template support:

• Agents must hardcode template-specific field values.
• Template changes must be duplicated in prompts or external automation.
• Work items created via MCP can differ from work items created through the Azure DevOps UI.
• Organisations lose a single source of truth for work item defaults.

Example scenarios

Scenario 1: Creating backlog items

A team maintains a "User Story" template containing:

• Default Area Path
• Tags
• Story layout
• Definition of Ready checklist

An AI agent should be able to create a new story from this template and only provide the title and description.

Scenario 2: Incident management

A support team uses a Bug template with:

• Severity
• Priority
• Assigned team
• Required custom fields

An AI agent analysing alerts could create bugs using the approved template instead of replicating those values in prompts.

Scenario 3: Automated work item creation

Organisations frequently automate work item creation from:

• Monitoring systems
• Security scanners
• GitHub issues
• Pull request reviews

Using Azure DevOps templates would ensure consistent work item configuration across both human-created and AI-created items.

Suggested workflow

1. Agent calls wit_get_work_item_templates
2. User selects a template (or agent selects by name)
3. Agent calls wit_create_work_item_from_template
4. Optional field values override template defaults

This would align MCP-created work items with existing Azure DevOps Boards functionality and reduce the amount of custom logic required in AI agents and integrations.

[Dan Hellem (danhellem)]

I don't think this is something we are going provide in the short term. You can set the template up in your agent or skill and generate the work item that way. I will add this to our backlog though and if we get more folks asking for it, we will re-consider

[Chris (cpAdm)]

Thanks for the quick response.

At the moment we've worked around this by storing our work item templates in our local repository and having the agent use those definitions when creating work items.

The main drawback is that this introduces duplication of configuration. When a template changes, it must be updated in two places:

1. In Azure DevOps, so that users who create work items through the Azure DevOps UI continue to get the latest version of the template.
2. In the repository, so that MCP-based agents generate work items using the same updated template.

This means the Azure DevOps work item template is no longer the single source of truth, and there is a risk that the UI and MCP experiences gradually diverge over time.

For now we'll continue using the repository-based approach, but I wanted to provide that additional context on why native template support would be valuable from a maintainability and governance perspective.

Thanks again for considering the request and adding it to the backlog.