MCP Azure DevOps Server

get_team_iterations

Retrieve team sprint schedules and date ranges from Azure DevOps to view active iterations, plan work, and track team capacity.

Instructions

    Retrieves the iterations (sprints) assigned to a specific team.
    
    Use this tool when you need to:
    - View a team's sprint schedule
    - Find date ranges for iterations
    - Determine which iteration is currently active
    - Plan work based on team's iteration calendar
    
    IMPORTANT: Iterations in Azure DevOps define time periods for planning
    and tracking work. They determine sprint dates and are used for
    capacity planning, burndown charts, and velocity calculations.
    
    Args:
        project_name_or_id: The name or ID of the team project
        team_name_or_id: The name or ID of the team
        current: If True, return only the current iteration
            
    Returns:
        Formatted string containing team iteration information including
        names, date ranges, and time frames (past/current/future),
        formatted as markdown

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_name_or_id": "<project_name_or_id>",
      "team_name_or_id": "<team_name_or_id>"
    },
    "name": "get_team_iterations"
  }
}

Input Schema

Name	Required	Description	Default
`project_name_or_id`	Yes
`team_name_or_id`	Yes
`current`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedAug 15, 2025

TDQS

A4.6/5.0

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 what the tool does (retrieves iterations), explains the Azure DevOps context, and specifies the return format (formatted string as markdown). However, it doesn't mention potential limitations like authentication requirements, rate limits, or error conditions.

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 scenarios, important context, parameters, returns) and every sentence adds value. It's appropriately sized for a tool with 3 parameters and no annotations, with no redundant information.

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?

For a read operation with 3 parameters and no output schema, the description provides good completeness: clear purpose, usage guidelines, parameter explanations, and return format specification. The main gap is the lack of behavioral details like authentication or error handling, but given the tool's relative simplicity, it's mostly adequate.

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

Parameters4/5

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

With 0% schema description coverage, the description compensates well by explaining all three parameters in the Args section, clarifying their purpose and providing the 'current' parameter's filtering behavior. It adds meaningful context beyond the bare schema, though it doesn't specify format details for project/team identifiers.

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 tool's purpose with a specific verb ('Retrieves') and resource ('iterations (sprints) assigned to a specific team'), distinguishing it from sibling tools like get_all_teams or get_team_members. It explicitly defines what iterations are in Azure DevOps context.

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 provides explicit usage scenarios in a bulleted list (view sprint schedule, find date ranges, determine active iteration, plan work) and includes an IMPORTANT section explaining the broader context of iterations in Azure DevOps. This gives 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.