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

[Steve Beaugé (stevebeauge)]

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

Tool	Calls	Avg response	Max observed
wit_work_item_write	65	~10 KB	~52 KB
wit_work_item_link_write	31	~9 KB	~32 KB
wit_work_item_comment_write	24	~8 KB	~17.5 KB
repo_pull_request_thread (list)	13	~21 KB	~50 KB

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.

Part of the response	Size
fields (35 fields)	21.4 KB, of which System.Description = 15.3 KB
relations (19 entries, the item's whole relation list)	4.8 KB
links	0.9 KB
id, rev, url: what the caller actually needs	~0.1 KB

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.

[Dan Hellem (danhellem)]

We are not getting any other folks reporting this as an issue. It is returning results as expected. I am happy to keep an eye on the issue and if we get others reporting the concern, we can re-consider.