Add optimistic concurrency guard to work item update tools

[aroje]

Summary

Enhance the existing Azure DevOps MCP work item update tools with optional
optimistic concurrency support so updates can fail safely instead of silently
overwriting work item changes made by another user.

Tools

Enhance the following existing tools with full parameter support, including
optional ones.

wit_update_work_item: Update fields on a single Azure DevOps work item

Current behavior updates fields by work item ID.

Add optional optimistic concurrency support:

• Add optional parameter: expectedRev.
• When expectedRev is provided, prepend the following JSON Patch operation to
  the work item update request:

{
  "op": "test",
  "path": "/rev",
  "value": 7
}

Expected behavior:

• If the current work item revision matches expectedRev, apply the update normally.
• If the current work item revision does not match expectedRev, Azure DevOps
  should reject the update and no fields should be modified.
• Return a clear stale-update error message.

Example request:

{
  "id": 12345,
  "expectedRev": 7,
  "updates": [
    {
      "op": "replace",
      "path": "/fields/System.Description",
      "value": "Updated description"
    }
  ]
}

wit_update_work_items_batch: Update fields on multiple Azure DevOps work items

Current behavior groups field updates by work item ID and sends them through the
Azure DevOps batch API.

Add optional optimistic concurrency support per work item:

• Add optional parameter per update item or per grouped work item: expectedRev.
• When expectedRev is provided for a work item, prepend the JSON Patch /rev
  test operation to that work item's PATCH body.
• Each work item should be guarded independently.

Expected behavior:

• A stale work item update should fail without modifying that work item.
• Other work item updates in the batch should preserve the existing batch behavior.
• The response should make it clear which work items succeeded and which failed
  due to stale revision.

Remote MCP equivalents

Apply equivalent behavior to the remote grouped dispatcher if applicable.

wit_work_item_write with action update

Equivalent to wit_update_work_item.

wit_work_item_write with action update_batch

Equivalent to wit_update_work_items_batch.

Rules

1. Adhere strictly to existing project standards and coding conventions.
2. Preserve current behavior when expectedRev is not provided.
3. Use Azure DevOps JSON Patch revision testing with op: "test" and
   path: "/rev" when expectedRev is provided.
4. Ensure the revision test and field updates are sent in the same PATCH request
   so the check and update are atomic.
5. Return a clear stale-update error when the revision check fails, for example:

Stale update: work item 12345 changed since expected revision 7. No fields were modified.

1. Do not implement this as preflight fetch-and-compare only. A preflight check
   is not atomic because another user can update the work item between the fetch
   and the write.
2. Add or update tests for single work item update without expectedRev, single
   work item update with expectedRev, batch update without expectedRev,
   batch update with per-work-item expectedRev, and stale revision failure
   handling.

[danhellem]

I don't think this is something we are going to support right. At least until we get some more reqeuests for it.

[aroje]

Thanks for the quick response. I understand not prioritizing this until there is more demand.

That said, I’d like to highlight that I don’t see this as just a convenience feature. Without a revision guard, MCP-driven work item updates can silently overwrite changes made by another user in the meantime. In practice, this means the tool cannot guarantee data integrity for update workflows.

Since Azure DevOps already supports the required backend behavior through a JSON Patch operation on /rev, even a minimal implementation would be valuable: an optional expectedRev parameter that fails the update when the item has changed. That would be enough to prevent silent overwrites, while keeping the current behavior unchanged when the parameter is not provided.

I understand if this is not on the roadmap right now, but I believe this is an important safety gap for agent-driven write scenarios.