Skip to main content
Glama
Vortiago
by Vortiago

get_work_item_templates

Retrieve work item templates for a team in Azure DevOps to find available templates, get template IDs, or filter by work item type.

Instructions

    Gets a list of all work item templates for a team.
    
    Use this tool when you need to:
    - Find available templates for creating work items
    - Get template IDs for use in other operations
    - Filter templates by work item type
    
    Args:
        team_context: Dictionary containing team information with keys:
            project: Project name (Optional if project_id is provided)
            project_id: Project ID (Optional if project is provided)
            team: Team name (Optional if team_id is provided)
            team_id: Team ID (Optional if team is provided)
        work_item_type: Optional work item type name to filter templates
        
    Returns:
        A formatted table of all templates with names, work item types,
        and descriptions
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
team_contextYes
work_item_typeYes

Implementation Reference

  • The main handler function for the 'get_work_item_templates' tool, decorated with @mcp.tool(). It handles input parameters, retrieves the work item tracking client, and delegates to the implementation helper.
    @mcp.tool()
    def get_work_item_templates(
        team_context: dict, 
        work_item_type: Optional[str]
    ) -> str:
        """
        Gets a list of all work item templates for a team.
        
        Use this tool when you need to:
        - Find available templates for creating work items
        - Get template IDs for use in other operations
        - Filter templates by work item type
        
        Args:
            team_context: Dictionary containing team information with keys:
                project: Project name (Optional if project_id is provided)
                project_id: Project ID (Optional if project is provided)
                team: Team name (Optional if team_id is provided)
                team_id: Team ID (Optional if team is provided)
            work_item_type: Optional work item type name to filter templates
            
        Returns:
            A formatted table of all templates with names, work item types,
            and descriptions
        """
        try:
            wit_client = get_work_item_client()
            return _get_work_item_templates_impl(
                team_context, work_item_type, wit_client)
        except AzureDevOpsClientError as e:
            return f"Error: {str(e)}"
  • Core helper function that performs the actual retrieval of work item templates using the Azure DevOps client, formats them into a markdown table, and handles errors.
    def _get_work_item_templates_impl(
        team_context: dict, 
        work_item_type: Optional[str],
        wit_client: WorkItemTrackingClient
    ) -> str:
        """Implementation of work item templates retrieval."""
        try:
            team_ctx = _create_team_context(team_context)
            templates = wit_client.get_templates(team_ctx, work_item_type)
            
            team_display = team_context.get('team') or team_context.get('team_id')
            
            if not templates:
                scope = (f"work item type '{work_item_type}' in " 
                        if work_item_type else "")
                return f"No templates found for {scope}team {team_display}."
            
            # Create header
            project_display = (team_context.get('project') or 
                              team_context.get('project_id'))
            header = (f"# Work Item Templates for Team: {team_display} "
                     f"(Project: {project_display})")
            if work_item_type:
                header += f" (Filtered by type: {work_item_type})"
            
            headers = ["Name", "Work Item Type", "Description"]
            
            # Use list comprehension for table rows
            rows = [
                f"| {template.name} | " 
                f"{getattr(template, 'work_item_type_name', 'N/A')} | " +
                f"{getattr(template, 'description', 'N/A')} |"
                for template in templates
            ]
            
            return f"{header}\n\n" + _format_table(headers, rows)
        except Exception as e:
            return f"Error retrieving templates: {str(e)}"
  • The registration call within the work items tools package init that registers the templates tools, including 'get_work_item_templates'.
    templates.register_tools(mcp)
  • Helper function to create the TeamContext object required by the Azure DevOps API from the input team_context dictionary.
    def _create_team_context(team_context_dict):
        """Create a TeamContext object from a dictionary."""
        from azure.devops.v7_1.work_item_tracking.models import TeamContext
        return TeamContext(
            project=team_context_dict.get('project'),
            project_id=team_context_dict.get('project_id'),
            team=team_context_dict.get('team'),
            team_id=team_context_dict.get('team_id')
        )
  • Utility helper to format lists into markdown tables used for displaying template lists.
    def _format_table(headers, rows):
        """Format data as a markdown table."""
        result = []
        result.append("| " + " | ".join(headers) + " |")
        result.append("| " + " | ".join(["----"] * len(headers)) + " |")
        result.extend(rows)
        return "\n".join(result)
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It describes the tool as a read operation ('Gets') and mentions filtering and return format, but lacks details on permissions, rate limits, pagination, or error handling. It adds some behavioral context but is incomplete for a tool with nested objects and no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, usage guidelines, args, returns) and uses bullet points efficiently. It's appropriately sized but could be slightly more concise by integrating the purpose into the usage section or trimming redundant phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (2 parameters with nested objects, no output schema, no annotations), the description is partially complete. It covers purpose, usage, and parameters well, but lacks details on behavioral aspects like authentication, errors, or output structure beyond a brief mention, leaving gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by detailing both parameters: 'team_context' is explained as a dictionary with specific keys and optionality rules, and 'work_item_type' is described as an optional filter. This adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Gets a list of all work item templates for a team' with a specific verb ('Gets') and resource ('work item templates'), and distinguishes it from sibling tools like 'get_work_item_template' (singular) and 'get_work_item_type'. However, it doesn't explicitly differentiate from 'get_work_item_types' or other list-like tools, keeping it from a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage scenarios ('Use this tool when you need to') with three bullet points, including finding templates, getting IDs, and filtering by type. It doesn't mention when not to use it or name specific alternatives among siblings, but the context is clear and helpful for guiding selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vortiago/mcp-azure-devops'

If you have feedback or need assistance with the MCP directory API, please join our Discord server