Create an Azure DevOps work item

Let your AI file Azure DevOps work items (bugs, tasks) the model never holds credentials for.

Create a work item (Bug by default) in an Azure DevOps project via the Boards REST API. The org, project, and work-item type are fixed at install; the PAT is the secret, entered in the browser as an HTTP Basic credential.

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_workitem

Create an Azure DevOps work item in the configured org/project. Input: title (required), description (optional), tags (optional, semicolon-separated).

Setup walkthrough

1. AZURE_DEVOPS_PAT: In Azure DevOps: User settings, Personal access tokens, New Token, scope Work Items (Read & write). 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>`.

Intent schema

{
  "type": "object",
  "required": [
    "title"
  ],
  "properties": {
    "title": {
      "type": "string",
      "maxLength": 255
    },
    "description": {
      "type": "string"
    },
    "tags": {
      "type": "string",
      "description": "Semicolon-separated tags."
    }
  }
}

Install-time parameters

org

install-time: Azure DevOps organization.

project

install-time: Project within the organization.

type

install-time: Work item type (Bug, Task, User Story...).

Transformation

[ { "op": "add", "path": "/fields/System.Title", "value": $body.title }, { "op": "add", "path": "/fields/System.Description", "value": ($exists($body.description) ? $body.description : "") }, { "op": "add", "path": "/fields/System.Tags", "value": ($exists($body.tags) ? $body.tags : "") } ]

Delivery target

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

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

Gotchas

• The work-item type rides the URL path with a literal dollar sign ($Bug, $Task) - note the doubled $$ in the template so $install.type materializes to `$Bug`.
• Body is JSON Patch (application/json-patch+json), not plain JSON - the transformation emits the op/path/value array.
• Success is 200 with the created item (System.Id in the response).
• PATs use HTTP Basic with a base64(':' + PAT) value; a raw PAT will 401 (or 203 to a sign-in page).
• 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.title). 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 work item whose title names itself a test, for example {"title": "Test: FlurryPORT pipe check, safe to close"} and nothing else. Install the type as Task if you are still choosing, and close or delete the item in Azure DevOps afterward.

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