Loading ToolBench
MCP server for Azure DevOps integration, providing tools to manage projects, work items, iterations, pipelines, and teams
29 tools with consistent verb-noun naming (list_, get_, create_, update_, add_). All tools have descriptions (10-200 chars, baseline 194). Input schemas present with typed parameters and descriptions. However, output schemas are undocumented, LLMs cannot infer response structure for chaining. Error handling is minimal; no recovery guidance or actionable error messages. Missing tool annotations (readOnlyHint, destructiveHint). Parameter descriptions lack format constraints (e.g., 'iteration_id' has no format spec). No pagination documented despite tools returning lists. Security: credentials injected server-side (good), but no permission gates or audit trail declarations.
Add a comment to a specific work item.
Assign an existing iteration (by ID) to a specific team.
Create a new iteration (sprint) under the specified project. Example: create_iteration("MyProject", "Sprint 10", "Project\\Iteration")
Create a new work item. Example: create_work_item("MyProject", "Task", {"System.Title": "New Task"})
Get all changes associated with a build.
Get all revisions for a build definition.
Output schemas undocumented. LLMs cannot infer response structure (fields, types, nested objects) for downstream tool chaining. E.g., get_work_item returns unknown fields; agents cannot extract IDs for follow-up calls.
No pagination documented. Tools returning lists (list_projects, list_runs, list_backlogs) lack page/offset/limit parameters and total_count in response. Large result sets will blow context windows.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Agents cannot distinguish safe reads from destructive writes without parsing descriptions. update_build_stage, run_pipeline, create_work_item lack destructiveHint.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
List all build definitions in the organization.
Get build logs for a specific build.
Get a specific build log by log ID.
Get the current status of a build.
Get all builds, optionally filtered by build definition ID.
Search for identity IDs by display name (user or group).
Get details for a pipeline run.
Retrieve a single work item by ID.
Find a work item ID by its title.
Retrieve multiple work items by their IDs.
Get all work items assigned to a specific iteration for a team.
List work items under a specific backlog category. Example: backlog_category='Microsoft.EpicCategory'
List backlog categories (Epics, Features, Stories, etc.).
List all teams within a specific Azure DevOps project.
List all Azure DevOps projects in the organization.
List all pipeline runs, optionally filtered by pipeline ID.
List all iterations (sprints) for a specific team within a project.
List comments for a specific work item.
Get the authenticated user's assigned work items.
Queue a new pipeline run.
Returns a detailed summary of a work item: - Title, type, state - Children (Features/Stories) - Blockers
Update the status of a stage in a build (if supported).
Update an existing work item by ID. Example: update_work_item("MyProject", 1234, {"System.State": "Closed"})
Parameter descriptions lack format constraints. 'iteration_id' (string) has no format spec; 'definition_id' (integer) lacks range (min/max). LLMs cannot validate inputs before calling.
Error handling absent. No recovery guidance, error classification, or actionable messages. E.g., 'project not found' should suggest available projects; 'invalid work_item_id' should explain valid format.