Skip to main content
Glama
Vortiago
by Vortiago

get_team_area_paths

Retrieve area paths assigned to a specific team to understand their work responsibilities and configure boards and backlogs in Azure DevOps.

Instructions

    Retrieves the area paths assigned to a specific team.
    
    Use this tool when you need to:
    - Understand a team's areas of responsibility
    - Check default area path assignments
    - Determine how work is classified and routed to teams
    - Set up board and backlog configurations
    
    IMPORTANT: Area paths in Azure DevOps determine which work items appear
    on a team's backlogs and boards. The default area path is used when
    creating new work items through a team's interface.
    
    Args:
        project_name_or_id: The name or ID of the team project
        team_name_or_id: The name or ID of the team
            
    Returns:
        Formatted string containing team area path information including
        the default area path and all assigned paths, with indicators for
        paths that include sub-areas
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_name_or_idYes
team_name_or_idYes

Implementation Reference

  • Core handler implementation that executes the tool logic: creates TeamContext, calls Azure DevOps WorkClient.get_team_field_values to retrieve team area paths, handles errors, and formats the result using a helper function.
    def _get_team_area_paths_impl(
        work_client,
        project_name_or_id: str,
        team_name_or_id: str
    ) -> str:
        """
        Implementation of team area paths retrieval.
        
        Args:
            work_client: Work client
            project_name_or_id: The name or ID of the team project
            team_name_or_id: The name or ID of the team
                
        Returns:
            Formatted string containing team area path information
        """
        try:
            # Create a TeamContext object
            team_context = TeamContext(
                project=project_name_or_id,
                team=team_name_or_id
            )
            
            # Get the team field values
            team_field_values = work_client.get_team_field_values(team_context)
            
            if not team_field_values:
                return (f"No area paths found for team {team_name_or_id} "
                        f"in project {project_name_or_id}.")
            
            return _format_team_area_path(team_field_values)
                
        except Exception as e:
            return f"Error retrieving team area paths: {str(e)}"
  • MCP tool registration and public handler function decorated with @mcp.tool(), including schema description in docstring, parameter definitions, and delegation to the core implementation.
    @mcp.tool()
    def get_team_area_paths(
        project_name_or_id: str,
        team_name_or_id: str
    ) -> str:
        """
        Retrieves the area paths assigned to a specific team.
        
        Use this tool when you need to:
        - Understand a team's areas of responsibility
        - Check default area path assignments
        - Determine how work is classified and routed to teams
        - Set up board and backlog configurations
        
        IMPORTANT: Area paths in Azure DevOps determine which work items appear
        on a team's backlogs and boards. The default area path is used when
        creating new work items through a team's interface.
        
        Args:
            project_name_or_id: The name or ID of the team project
            team_name_or_id: The name or ID of the team
                
        Returns:
            Formatted string containing team area path information including
            the default area path and all assigned paths, with indicators for
            paths that include sub-areas
        """
        try:
            work_client = get_work_client()
            return _get_team_area_paths_impl(
                work_client,
                project_name_or_id,
                team_name_or_id
            )
        except AzureDevOpsClientError as e:
            return f"Error: {str(e)}"
  • Helper function to format the retrieved team field values into a structured markdown string showing default and all area paths with include_children indicators.
    def _format_team_area_path(team_field_values) -> str:
        """
        Format team area path information.
        
        Args:
            team_field_values: Team field values object to format
            
        Returns:
            String with team area path details
        """
        formatted_info = ["# Team Area Paths"]
        
        # Add default area path
        if (hasattr(team_field_values, "default_value") and 
                team_field_values.default_value):
            formatted_info.append(
                f"Default Area Path: {team_field_values.default_value}")
        
        # Add all area paths
        if hasattr(team_field_values, "values") and team_field_values.values:
            formatted_info.append("\n## All Area Paths:")
            for area_path in team_field_values.values:
                value_str = f"- {area_path.value}"
                if (hasattr(area_path, "include_children") and 
                        area_path.include_children):
                    value_str += " (Including sub-areas)"
                formatted_info.append(value_str)
        
        return "\n".join(formatted_info)
  • Registration entry point for the teams feature, which calls tools.register_tools(mcp) to register all team tools including get_team_area_paths.
    def register(mcp):
        """
        Register all teams components with the MCP server.
        
        Args:
            mcp: The FastMCP server instance
        """
        tools.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 explains what the tool returns (formatted string with default area path, all assigned paths, and sub-area indicators) and provides important context about how area paths function in Azure DevOps. However, it doesn't mention potential errors, authentication requirements, or rate limits.

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 with clear sections (purpose, usage guidelines, important context, parameters, returns) and every sentence earns its place. It's appropriately sized for a tool with 2 parameters and no annotations, providing comprehensive information without unnecessary verbosity.

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

Completeness5/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 provides complete coverage. It explains what the tool does, when to use it, the parameters, the return format, and the broader system context. The Returns section effectively substitutes for a missing output schema.

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 clearly documenting both parameters (project_name_or_id and team_name_or_id) in the Args section. It explains what each parameter represents and provides the important detail that they accept either names or IDs, adding significant value beyond the bare schema.

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 specific action ('Retrieves the area paths') and resource ('assigned to a specific team'), distinguishing it from sibling tools like get_all_teams or get_team_members. It provides a precise verb+resource combination that leaves no ambiguity about what the tool does.

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 explicitly lists four specific use cases (understanding areas of responsibility, checking default assignments, determining classification/routing, setting up configurations) and includes an IMPORTANT section explaining the broader context of area paths in Azure DevOps. This provides clear guidance on when to use this tool versus alternatives.

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