Skip to main content
Glama
Vortiago
by Vortiago

get_work_item_comments

Retrieve all comments for a specific Azure DevOps work item to review discussion history, see team feedback, and understand task evolution.

Instructions

    Retrieves all comments associated with a specific work item.

    Use this tool when you need to:
    - Review discussion history about a work item
    - See feedback or notes left by team members
    - Check if specific questions have been answered
    - Understand the context and evolution of a work item
    
    Args:
        id: The work item ID
        project: Optional project name. If not provided, will be 
            determined from the work item.
        
    Returns:
        Formatted string containing all comments on the work item, 
        including author names, timestamps, and content, organized 
        chronologically and formatted as markdown
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
projectNo

Implementation Reference

  • MCP tool handler 'get_work_item_comments' that orchestrates comment retrieval by getting the client and calling the implementation helper, with error handling.
    @mcp.tool()
    def get_work_item_comments(
        id: int,
        project: Optional[str] = None
    ) -> str:
        """
        Retrieves all comments associated with a specific work item.
    
        Use this tool when you need to:
        - Review discussion history about a work item
        - See feedback or notes left by team members
        - Check if specific questions have been answered
        - Understand the context and evolution of a work item
        
        Args:
            id: The work item ID
            project: Optional project name. If not provided, will be 
                determined from the work item.
            
        Returns:
            Formatted string containing all comments on the work item, 
            including author names, timestamps, and content, organized 
            chronologically and formatted as markdown
        """
        try:
            wit_client = get_work_item_client()
            return _get_work_item_comments_impl(id, wit_client, project)
        except AzureDevOpsClientError as e:
            return f"Error: {str(e)}"
  • Core helper function '_get_work_item_comments_impl' that implements the logic to fetch comments from the Azure DevOps WIT client, auto-detect project if needed, and format them for output.
    def _get_work_item_comments_impl(
        item_id: int,
        wit_client: WorkItemTrackingClient,
        project: Optional[str] = None
    ) -> str:
        """
        Implementation of work item comments retrieval.
        
        Args:
            item_id: The work item ID
            wit_client: Work item tracking client
            project: Optional project name
                
        Returns:
            Formatted string containing work item comments
        """
        # If project is not provided, try to get it from the work item
        if not project:
            project = _get_project_for_work_item(item_id, wit_client)
            
            if not project:
                return f"Error retrieving work item {item_id} to determine project"
        
        # Get comments using the project if available
        comments = wit_client.get_comments(project=project, work_item_id=item_id)
        
        # Format the comments
        formatted_comments = [
            _format_comment(comment) for comment in comments.comments
        ]
        
        if not formatted_comments:
            return "No comments found for this work item."
        
        return "\n\n".join(formatted_comments)
  • Helper function to format individual comment objects into readable markdown strings with author, date, and text.
    def _format_comment(comment) -> str:
        """
        Format a work item comment for display.
        
        Args:
            comment: Comment object to format
            
        Returns:
            Formatted string representation of the comment
        """
        # Format the date if available
        created_date = ""
        if hasattr(comment, 'created_date') and comment.created_date:
            created_date = f" on {comment.created_date}"
        
        # Format the author if available
        author = "Unknown"
        if hasattr(comment, 'created_by') and comment.created_by:
            if (hasattr(comment.created_by, 'display_name') and 
                    comment.created_by.display_name):
                author = comment.created_by.display_name
        
        # Format the comment text
        text = "No text"
        if hasattr(comment, 'text') and comment.text:
            text = comment.text
        
        return f"## Comment by {author}{created_date}:\n{text}"
  • Helper function to retrieve the project name from a work item, used when project is not provided.
    def _get_project_for_work_item(
        item_id: int,
        wit_client: WorkItemTrackingClient
    ) -> Optional[str]:
        """
        Get the project name for a work item.
        
        Args:
            item_id: The work item ID
            wit_client: Work item tracking client
                
        Returns:
            Project name or None if not found
        """
        try:
            work_item = wit_client.get_work_item(item_id)
            if work_item and work_item.fields:
                return work_item.fields.get("System.TeamProject")
        except Exception:
            pass
        
        return None
  • Registration point where comments.register_tools(mcp) is called, which in turn defines and registers the get_work_item_comments tool.
    def register_tools(mcp) -> None:
        """
        Register all work item tools with the MCP server.
        
        Args:
            mcp: The FastMCP server instance
        """
        query.register_tools(mcp)
        read.register_tools(mcp)
        comments.register_tools(mcp)
        create.register_tools(mcp)
        types.register_tools(mcp)
        templates.register_tools(mcp)
        process.register_tools(mcp)
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it retrieves comments, includes author names, timestamps, and content, organizes them chronologically, and returns them as a formatted markdown string. This covers key aspects like output format and organization, though it doesn't mention potential limitations like pagination, rate limits, or authentication needs.

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

Conciseness5/5

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

The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bulleted list of use cases, then details parameters and returns in labeled sections. Every sentence adds value without redundancy, making it easy to scan and understand.

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

Completeness4/5

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

Given the tool's moderate complexity (2 parameters, no annotations, no output schema), the description is largely complete. It covers purpose, usage, parameters, and return format. However, it doesn't address potential behavioral aspects like error conditions (e.g., invalid ID), pagination for many comments, or authentication requirements, leaving minor gaps in full context.

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?

The schema description coverage is 0%, so the description must fully compensate. It provides clear semantics for both parameters: 'id' is described as 'The work item ID', and 'project' is explained as 'Optional project name. If not provided, will be determined from the work item.' This adds essential meaning beyond the bare schema, clarifying the optional nature and default behavior of the 'project' parameter.

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

Purpose5/5

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

The description clearly states the verb ('retrieves') and resource ('all comments associated with a specific work item'), making the purpose explicit. It distinguishes this tool from siblings like 'add_work_item_comment' (which creates comments) and 'get_work_item' (which retrieves the work item itself, not its comments), providing specific differentiation.

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

Usage Guidelines5/5

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

The description includes a bulleted list of specific use cases (e.g., 'Review discussion history', 'See feedback or notes', 'Check if specific questions have been answered'), giving explicit guidance on when to use this tool. While it doesn't explicitly mention when not to use it or name alternatives, the detailed context scenarios effectively guide appropriate usage.

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