Skip to main content
Glama
Sign In
ado-workflows-mcp

ado-workflows-mcp

by grimlor
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

move_work_items_to_sprint

Assign work items to a target sprint by updating their iteration path. Manually specify the work item IDs; child items are not moved automatically.

Instructions

Move work items to a target sprint by updating their iteration path.

Does not auto-include children — callers decide which IDs to move.

Args: project: Azure DevOps project name. work_item_ids: List of work item IDs to move. iteration_path: Target iteration path (e.g. "One\FY26\Q4\2Wk\2Wk22"). working_directory: Optional path for ADO context resolution.

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": "<project>",
      "work_item_ids": "<work_item_ids>",
      "iteration_path": "<iteration_path>",
      "working_directory": "<working_directory>"
    },
    "name": "move_work_items_to_sprint"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectYes
work_item_idsYes
iteration_pathYes
working_directoryYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.12.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description bears full transparency burden. It discloses that children are not auto-included, but omits potential side effects (e.g., state changes, notifications) and permissions needed. The mechanism (updating iteration path) is clear, but deeper behavioral details are lacking.

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 extremely concise: one line for purpose, one line for behavioral nuance, and a compact parameter list. Every sentence adds value, and the most important information is front-loaded.

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 moderate complexity, the description covers the core action, parameters, and a key behavioral trait (no children). It does not explain output format or error handling, but the presence of an output schema partially mitigates this. Still, for a mutation tool, more context on postconditions would be beneficial.

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?

Schema coverage is 0%, so description must define parameters. It provides clear, brief descriptions for all four parameters (project, work_item_ids, iteration_path, working_directory), adding meaning beyond the schema's type-only definitions. However, it could add more detail on allowed values or format.

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 'move' and the resource 'work items to a target sprint', with the mechanism 'by updating their iteration path'. It distinguishes itself from sibling tools like 'update_work_item' and 'clone_work_item' by its specific focus on moving multiple items to a sprint.

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 explicitly notes that children are not auto-included, guiding callers to decide which IDs to move. However, it does not contrast with similar tools like 'update_work_item' or 'clone_work_item' to specify when to use this tool versus those.

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

Deploy Server

Other Tools