Read Azure DevOps work items

Read fields for a batch of Azure DevOps work items by id: title, state, tags, priority, iteration.

Read a batch of Azure DevOps work items by id and get their fields back. The org and project are fixed at install; the PAT is the secret, entered in the browser as an HTTP Basic credential. Ids come from azure-devops-query or from anywhere you already know them, and the fields arrive on the replay execution. Two limits shape how you use it. Azure DevOps caps one batch at 200 ids and answers a longer list with 400. More sharply, every id in the batch has to exist: a single deleted or unknown id fails the WHOLE read with 404 rather than returning the rest, so drop stale ids before firing. Field names are Azure DevOps reference names rather than the labels on the board, so ask for System.Title and Microsoft.VSTS.Common.Priority, not Title and Priority. It is a read that uses POST, and like query it cannot ride the $batch endpoint, which refuses collection-level reads. That is why seeing the board takes two pipes rather than one.

The credential never enters the model context: it lives in the FlurryPORT secret store, deliveries are signed server-side, and every send returns a receipt your agent can quote.

npx flurryport mcp

Tools your agent gains

flry_azure_devops_read

Read fields for a batch of Azure DevOps work items in the configured org and project. Input: ids (required, up to 200 integers), fields (optional field reference names; omit for the default set). Returns nothing inline; the fields arrive on the replay execution, read them with get_replay_execution.

Setup walkthrough

1. AZURE_DEVOPS_PAT: In Azure DevOps: User settings, Personal access tokens, New Token. This recipe on its own needs only scope Work Items (Read); the same token needs Work Items (Read & write) if it also serves azure-devops-workitem or azure-devops-manage. The value to paste in the FlurryPORT secret page is the HTTP Basic credential, NOT the raw token: run `printf ':YOUR_PAT' | base64` and paste the result. The recipe sends it as `Authorization: Basic <value>`. A raw PAT answers 401, or 203 with a sign-in page.

Intent schema

{
  "type": "object",
  "required": [
    "ids"
  ],
  "properties": {
    "ids": {
      "type": "array",
      "maxItems": 200,
      "items": {
        "type": "integer"
      },
      "description": "Work item ids to read. Azure DevOps caps one batch at 200 ids."
    },
    "fields": {
      "type": "array",
      "items": {
        "type": "string"
      },
      "description": "Azure DevOps field reference names to return. Omit it and the pipe asks for System.Id, System.Title, System.State, System.Tags, Microsoft.VSTS.Common.Priority, and System.IterationPath."
    }
  }
}

Install-time parameters

org

install-time: Azure DevOps organization.

project

install-time: Project within the organization.

Transformation

{ "ids": $body.ids, "fields": ($exists($body.fields) ? $body.fields : ["System.Id","System.Title","System.State","System.Tags","Microsoft.VSTS.Common.Priority","System.IterationPath"]) }

Delivery target

POST https://dev.azure.com/$install.org/$install.project/_apis/wit/workitemsbatch?api-version=7.1

Placeholders like $secrets.NAME resolve server-side at delivery, never in the agent.

Gotchas

• Every id in the batch must exist. One deleted or unknown id fails the WHOLE read with 404, not a partial result; drop stale ids from the list before firing (proven live 2026-08-01 against recycled work items).
• On plans without full response bodies the stored response is a 4096-byte preview. Keep a read to 10 ids or fewer there and check ResponseBodyTruncated on the execution before parsing: the largest 10-id batch measured 3628 of 4096 bytes. On plans with full response bodies, read whole batches.
• Azure DevOps caps one batch at 200 ids. A longer list answers 400.
• Field names are Azure DevOps reference names, not the labels on the board: System.Title, System.State, System.Tags, Microsoft.VSTS.Common.Priority, System.IterationPath.
• This is a read that uses POST. Success is 200 with a value array carrying the requested items.
• Fields arrive on the replay execution the fire created, not on the capture. Read them with get_replay_execution.
• This call cannot ride the Azure DevOps $batch endpoint. $batch answers a collection-level read with 404 Unsupported Batch operation, which is why read is its own pipe.
• The Accept-Encoding identity header in the target template is load-bearing: without it Azure DevOps gzips responses and the stored response preview is unreadable binary. With it, stored responses are plain JSON (proven live on prod 2026-08-03).
• Bind this pipe's transformation with the predicate $exists($body.ids). When two or more azure-devops pipes share one capture endpoint, every binding must carry its routing predicate at bind time, and the family's predicates are mutually exclusive by design: azure-devops-workitem routes on $exists($body.title), azure-devops-read on $exists($body.ids), azure-devops-query on $exists($body.wiql), azure-devops-manage on $exists($body.items). An unpredicated binding fires on every intent that reaches the endpoint (live repro 2026-08-03: a workitem binding bound without its predicate fired on every read intent).
• Safest test fire: one or two ids you know are live, default fields, for example {"ids": [12, 13]}. It reads and changes nothing.

Where this fits

• Destination: Azure DevOps
• Part of the Azure DevOps work items suite
• Project tracking recipes
• What agent tokens can and cannot do
• All recipes

Related recipes