Feature Request: Work Item File Attachment Upload

[matjaz-sega]

Problem

The MCP server currently provides wit_get_work_item_attachment (download) but has no corresponding upload capability. Agents that need to attach generated files (specs, plans, reports) to a work item must either fall back to the az devops CLI extension (which has known permission issues on Windows) or implement a raw REST API call using az account get-access-token and Invoke-RestMethod.

This forces agents that should be analysis-only to request broad shell execution permissions (run_in_terminal) just to perform a simple file upload.

Proposed solution

Add two new tools:

wit_upload_attachment

Upload file content to ADO attachment storage. Returns the attachment URL.

Parameters:

• project (string)
• fileName (string)
• content (string, base64-encoded)

Returns: { "url": "https://dev.azure.com/.../_apis/wit/attachments/<guid>?fileName=..." }

Maps to: POST /_apis/wit/attachments?fileName={fileName}&api-version=7.1

---

wit_add_attachment

Link an already-uploaded attachment URL to a work item.

Parameters:

• workItemId (number)
• attachmentUrl (string)
• fileName (string)
• comment (string, optional)

Maps to: PATCH /_apis/wit/workItems/{id} with an add /relations/- operation of type AttachedFile.

---

Why two tools?

The ADO REST API uses a two-step process (upload first, then link). Keeping them separate allows uploading multiple files and linking them in one patch if desired, and mirrors the underlying API shape.

Workaround currently required

$token = az account get-access-token --resource 499b84ac-1321-427f-aa17-267ca6975798 --query accessToken -o tsv
$resp = Invoke-RestMethod "$org/$project/_apis/wit/attachments?fileName=spec.md&api-version=7.1" `
    -Method Post -Headers @{ Authorization = "Bearer $token"; "Content-Type" = "application/octet-stream" } `
    -Body ([System.IO.File]::ReadAllBytes($path))
# then PATCH work item with $resp.url ...

This is exactly what the MCP server should encapsulate.