[REMOTE] Write tools return the full work item: ~1 MB/week of unused payload in agent sessions (follow-up to #562) #1679

Issue Type

• Feedback on Remote MCP Server
• Bug in Remote MCP Server
• Tool or feature request for Remote MCP Server

Tool(s)

• wit_work_item_write (update, add_child)
• wit_work_item_link_write (link)
• wit_work_item_comment_write (add)
• repo_pull_request_thread (list)

Description

Follow-up to #562, which was closed for lack of concrete examples. Write tools return the full work item (or the full comment) when the caller only needs a confirmation. Below are measurements and three real examples from one week of use.

I checked the documented configuration first: the X-MCP-Toolsets, X-MCP-Tools, X-MCP-Readonly and X-MCP-Insiders headers and the tool schemas offer no way to reduce response size.

Context

• Remote server (https://mcp.dev.azure.com), used from Claude Code.
• One developer, one week (2026-09-28 → 2026-10-04), 89 agent sessions. The agent did the backlog grooming, linking and commenting.
• Prompts were ordinary backlog tasks ("split this story into child tasks", "link these items", "post the findings as a comment").

Measured response sizes

Write calls alone returned ~1.1 MB over the week, i.e. roughly 300k tokens that went straight into the agent's context window.

Example 1: wit_work_item_link_write, action: "link", one link added, 30 KB returned

Input: one link between two existing work items, a couple of hundred bytes.
Response: the full work item.

fields holds five identity objects (AssignedTo, CreatedBy, ChangedBy, ActivatedBy, ClosedBy) of 923 bytes each, with the same 13 keys every time (values redacted):

{
  "descriptor": "aad.…", "displayName": "…", "url": "https://…",
  "links": { "avatar": { "href": "…" } }, "id": "…", "uniqueName": "…@…", "imageUrl": "…",
  "isContainer": false, "isAadIdentity": true, "inactive": false, "isDeletedInOrigin": false,
  "displayNameForXmlSerialization": "…", "urlForXmlSerialization": "…"
}

A 15 KB description has nothing to do with adding a link.

Example 2: wit_work_item_write, action: "add_child", 10 children created, 50 KB returned

The response is an array of the 10 new items, ~4.8 KB each: full fields (16 fields, including the Description the caller just sent, and CreatedBy/ChangedBy identities at 923 bytes each), plus relations and links. What the agent needs next is the 10 ids, about 60 bytes.

Example 3: wit_work_item_comment_write, action: "add", a 4.9 KB comment returned as 17.5 KB

The response echoes the comment twice: text (4.9 KB, the Markdown the caller just sent) and renderedText (6.2 KB of HTML), plus createdBy and modifiedBy identities (923 bytes each). What the agent needs next is the comment id.

Why it matters

After a write, the agent only needs to know that it succeeded, plus id, rev and url to chain the next call (the rev for a Test /rev operation, for instance). The rest of the payload is never read, but it crowds out useful context: compaction happens sooner and long sessions cost more. A session that updates 10–20 work items pays 100–300 KB for confirmations.

Suggestion

• Write actions return a minimal payload by default: id, rev, url, plus the comment id for comment writes.
• An opt-in parameter (e.g. fullOutput: true, as suggested in Unnecessarily verbose wit tool output #562) restores the current behaviour.
• Identity fields are reduced to displayName + uniqueName (or id) unless the full output is requested.
• repo_pull_request_thread list: an option to skip system/deleted comments, or to return thread status + first comment only.