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. Choose your scope. The azure-devops family is a ladder. File only: azure-devops-workitem on its own, which runs on the free Deckhand tier and fits a developer logging bugs without leaving the code. Read: azure-devops-query plus azure-devops-read, which needs two pipe slots and a plan that stores full response bodies (Bosun), runs on a PAT scoped Work Items (Read) when nothing else in the family is installed, and fits a developer checking their own assignments or a manager checking team progress. Manage: those two plus azure-devops-manage, which needs three pipe slots (First Mate) and a PAT scoped Work Items (Read & write), for a PM or QA grooming the whole backlog.

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.

Where this fits

• Destination: Azure DevOps
• Project tracking recipes
• What agent tokens can and cannot do
• All recipes

Related recipes