When calling list_work_items with a WIQL query, any fields included in the SELECT clause beyond the defaults are silently ignored. For example:
SELECT [System.Id], [System.Title], [Microsoft.VSTS.Common.StateChangeDate]
FROM WorkItems
WHERE ...
The StateChangeDate field is not returned in the response. The same applies to System.AreaPath and likely any other non-default field.
Root cause
The Azure DevOps Query By Wiql REST API only returns work item IDs regardless of the SELECT clause. The MCP then fetches full work item details in a follow-up call, but with a hardcoded field list — so the SELECT fields are never forwarded to the item fetch step.
Request
Allow the caller to specify additional fields to include in the follow-up work item fetch, either by:
- Parsing the
SELECT clause from the WIQL and forwarding those fields to the batch fetch, or
- Adding an explicit
fields parameter to the tool
Impact
Without this, callers cannot retrieve fields like StateChangeDate or AreaPath via a single tool call, forcing multiple round trips or workarounds.
When calling
list_work_itemswith a WIQL query, any fields included in theSELECTclause beyond the defaults are silently ignored. For example:The
StateChangeDatefield is not returned in the response. The same applies toSystem.AreaPathand likely any other non-default field.Root cause
The Azure DevOps Query By Wiql REST API only returns work item IDs regardless of the
SELECTclause. The MCP then fetches full work item details in a follow-up call, but with a hardcoded field list — so theSELECTfields are never forwarded to the item fetch step.Request
Allow the caller to specify additional fields to include in the follow-up work item fetch, either by:
SELECTclause from the WIQL and forwarding those fields to the batch fetch, orfieldsparameter to the toolImpact
Without this, callers cannot retrieve fields like
StateChangeDateorAreaPathvia a single tool call, forcing multiple round trips or workarounds.