Skip to main content

Overview

Before using this tool group, save an Azure DevOps connection as described in Azure DevOps. If connection_id is omitted, the tools use the effective default azure_devops connection for the current user (My default, then Role default). Actions that need a project use the explicit project parameter first and otherwise fall back to the connection’s saved default project. When multiple role defaults conflict, pass connection_id explicitly or set a user default. See Default connection layers.

Tool Name

Purpose

The azure_devops_boards_tools group integrates Genesis with Azure DevOps Boards. Create and update work items (including sprint moves), link work items to each other or to pull requests, read single or batched work item details, search with structured filters or WIQL, list sprints and boards, read comments and revision history, inspect links and text attachments, and retrieve sprint capacity for a specific team iteration. Successful agent writes also record best-effort observations on the Requests page when that feature is enabled.

Key Features

Create and update work items

Open new Azure DevOps work items, patch standard fields (including sprint moves via iteration_path), add comments, and link items to parents, children, related work, or pull requests.

Read issue context

Fetch one work item or up to 100 ids per batch; read comments, revision history, grouped links, and text attachments.

Query Boards data

Find work items with structured filters (ado_find_work_items) or hand-written WIQL (ado_search_work_items).

Explore team structure

List iterations (sprints), Kanban boards, and backlog levels for a team.

Inspect sprint capacity

Retrieve team capacity for a specific iteration to support planning.

Track managed work on Requests

When Requests is enabled, agent creates, updates, comments, and links through the write tools appear on the Activity tab with deep links back to Azure DevOps. Assignment automation can also poll for work items assigned to the connection identity and open orchestrator threads without an explicit agent tool call.

Requests page tracking

When Requests is enabled (GENESIS_SHOW_WORK), successful agent writes through ado_create_work_item, ado_update_work_item, and ado_link_work_items record observations in the Genesis ticket ledger. Each tracked row shows the Azure DevOps state, a normalized Genesis lifecycle state, the agent executor, the Genesis thread when one exists, and a deep link to the work item in Azure DevOps. Azure DevOps remains the system of record — ledger emission is observability only and never affects tool success.
  • Work items appear when an agent manages them through these write tools, or when Azure DevOps assignment automation picks up a work item assigned to the connection identity. Genesis does not bulk-import a backlog.
  • ado_get_work_item refreshes provider state for items Genesis already tracks; read-only lookups never import untracked backlog items.
  • Failed writes against an already-tracked item record an error on its timeline; failed writes against untracked ids are not imported.
  • State changes applied through state or fields={"System.State": ...} emit status-change events; comment-only updates keep the item in a working state so later observations can close the loop.
See Requests for the Activity and Health tabs and Ticket automation endpoints for the read API.

Input Parameters for Each Function

ado_create_work_item

ado_update_work_item

ado_update_work_item requires at least one field update or a comment. When comment is set, Genesis posts through the project-scoped comments API — pass project or save a default project on the connection. Write operations require a PAT with Work Items (Read & Write); a read-only PAT returns error_type: permission.
link_type semantics: parent makes target_work_item_id the parent of work_item_id; child makes it a child; related adds a plain relation; pull_request attaches the PR named by repo and pull_request_id as an artifact link. A work item cannot be linked to itself. Requires a PAT with Work Items (Read & Write).

ado_get_work_item

ado_get_work_items_batch

ado_search_work_items

ado_search_work_items returns id/url references in query_result.workItems only. Fetch full fields with ado_get_work_items_batch. Invalid WIQL returns error_type: invalid_wiql with the parser message. For common searches (for example “bugs assigned to me”), prefer ado_find_work_items.

ado_find_work_items

ado_list_iterations

ado_list_boards

ado_list_backlogs

ado_get_work_item_comments

ado_get_work_item_history

ado_download_attachment

ado_get_sprint_capacity

Workflow/How It Works

  1. Configure your effective default azure_devops connection in Azure DevOps, or pass connection_id.
  2. Use ado_create_work_item to open new tasks, bugs, or other work items.
  3. Use ado_get_work_item, ado_get_work_items_batch, and ado_update_work_item to inspect and modify existing work (including sprint moves with iteration_path).
  4. Use ado_link_work_items to relate work items or attach a pull request; use ado_get_work_item_links to inspect existing relationships.
  5. Use ado_find_work_items for structured searches (for example bugs assigned to you in the current sprint) or ado_search_work_items for hand-written WIQL.
  6. Use ado_list_iterations, ado_list_boards, and ado_list_backlogs to discover team structure; use ado_get_sprint_capacity for planning data.
  7. Use ado_get_work_item_comments, ado_get_work_item_history, and ado_download_attachment for discussion, audit, and attachment context.

Examples

Output

  • ado_create_work_item returns the created work_item. When parent_id is supplied and creation succeeds, the response can also include next_steps that remind the caller to link the parent work item in Azure DevOps.
  • ado_update_work_item returns success: true plus the updated work_item when fields were patched, and comment when a comment was added.
  • ado_link_work_items returns success: true, the updated work_item, and the link relation that was added.
  • ado_get_work_item returns work_item with every system and custom field. include_relations adds the raw relations array.
  • ado_get_work_items_batch returns work_items, count, and missing_ids for ids Azure DevOps did not return (deleted or not visible to the PAT).
  • ado_search_work_items returns the raw Azure DevOps query_result whose workItems are id/url references only. When you pass project, Genesis also echoes project in the response.
  • ado_find_work_items returns wiql, count, work_items (full details by default, or id/url references when include_details is false), and optionally missing_ids or detail_fetch_error.
  • ado_list_iterations returns iterations with id, name, path, and start/finish dates.
  • ado_list_boards returns boards with id, name, and url.
  • ado_list_backlogs returns backlogs with id, name, rank, and accepted work item types.
  • ado_get_work_item_comments returns comments, count, total_count, and continuation_token for paging.
  • ado_get_work_item_history returns revisions (field snapshots, oldest first) and count.
  • ado_get_work_item_links returns links grouped as parent, children, related, pull_requests, commits, attachments, hyperlinks, and other, plus per-group counts.
  • ado_download_attachment returns text (UTF-8, truncated past 100,000 characters), size_bytes, and truncated.
  • ado_get_sprint_capacity returns capacity.

Configuration Details

  • fields uses Azure DevOps field reference names such as System.Title, System.State, or Microsoft.VSTS.Common.Priority.
  • Calls that resolve a project require either an explicit project parameter or a default project on the saved connection.

Limitations or Notes

  1. ado_get_work_item accepts project for signature consistency; the work item is resolved by work_item_id. On ado_update_work_item, project (or a connection default) is required when comment is set because Azure DevOps serves the comments API only under a project URL.
  2. Comment text is never inlined by ado_get_work_item — use ado_get_work_item_comments for discussion content.
  3. ado_search_work_items and ado_find_work_items (with include_details=false) return id/url references; fetch full records with ado_get_work_items_batch (up to 100 ids per call).
  4. ado_find_work_items with iteration='current' requires team because Azure DevOps resolves the active sprint per team.
  5. ado_download_attachment reads text attachments only. Binary attachments (images, archives, office documents) return an error — open the attachment URL in Azure DevOps instead.
  6. parent_id on ado_create_work_item adds a follow-up hint only. Use ado_link_work_items with link_type='parent' or link_type='child' to create the hierarchy after creation.
  7. ado_update_work_item and ado_link_work_items are write operations. A PAT with Work Items read-only access returns error_type: permission (Azure DevOps may answer with HTTP 401 for insufficient scope).
  8. Requests-page tracking is best-effort. Ledger emission is guarded so malformed Azure DevOps payloads or ledger unavailability never change tool success responses.