Skip to content

perf(server): stop shipping full MCP tool results in thread payloads - #5482

Merged
t3dotgg merged 2 commits into
mainfrom
fix/mcp-tool-call-slimming
Aug 6, 2026
Merged

perf(server): stop shipping full MCP tool results in thread payloads#5482
t3dotgg merged 2 commits into
mainfrom
fix/mcp-tool-call-slimming

Conversation

@t3dotgg

@t3dotgg t3dotgg commented Aug 6, 2026

Copy link
Copy Markdown
Member

MCP tool calls were exempt from activity payload slimming: projectActivityPayload early-returns on itemType === "mcp_tool_call", so the full tool result rides along in every snapshot and live event. On MCP-heavy threads this dominates the wire — one imported thread ships 3.2 MB gzipped, with two-thirds of its post-slimming bytes being unslimmed MCP payloads (worst single call: a GitHub fetch_pr result at 1 MB).

The exemption existed because both clients render payload.data.item in the expanded work-log row. The fix keeps exactly the fields that row renders (tool, server, status, arguments, appContext, error, durationMs, plus toolName/input for the Claude-adapter shape) and summarizes the result to one 84-char line, same as regular tool output. Full payloads stay in SQLite, so an on-demand detail endpoint can be added later without data loss.

Measured against a real db seeded with six representative threads (2,991 MCP activities): 12.2 MB of MCP payload JSON drops to 546 KB (95.6% reduction). Both provider payload shapes (Codex data.item, Claude/OpenCode data.result) verified against real rows.

Note: this trades away in-app access to full historical MCP results (they were previously visible in the expanded row). Per the pagination investigation, that's an accepted temporary loss; the data remains in persistence.


Change made by Claude Fable 5 via Claude Code.


Note

Medium Risk
Changes the shape and fidelity of MCP activity data on thread snapshots and live events (lossy summaries), but scope is limited to projection with strong test coverage and no persistence changes.

Overview
MCP tool calls are no longer exempt from activity payload slimming in projectActivityPayload. Instead of passing mcp_tool_call through unchanged, the server now runs projectMcpToolCallData, which keeps only fields the expanded work-log row uses (tool, server, status, arguments, appContext, error, durationMs, plus Claude-style toolName/input) and replaces full tool results with a one-line summary via the same summarizeToolTextOutput helper used for other tools.

Codex-shaped payloads (data.item.result) and Claude/OpenCode-shaped payloads (data.result blocks) are both handled; internal metadata like _meta and large structuredContent are dropped. Changed file paths can still be collected into a files array. Full MCP results remain in persistence—only snapshot/live thread transports shrink.

Tests now assert large MCP fixtures compress dramatically and that web/mobile derived views stay aligned except for the intentional loss of full historical MCP result text in the expanded row.

Reviewed by Cursor Bugbot for commit 22f7a58. Bugbot is set up for automated code reviews on this repo. Configure here.

Note

Stop shipping full MCP tool results in thread payloads

  • Adds projectMcpToolCallData in ActivityPayloadProjection.ts to slim MCP tool-call payloads: only whitelisted fields (tool, server, arguments, etc.) are kept, and result content is replaced with a short text summary.
  • Handles both Codex-shaped (item array) and Claude-shaped (toolName/input/result) MCP data formats.
  • Changed files detected in results are surfaced as a files array on the slimmed payload.
  • Behavioral Change: activities with itemType === "mcp_tool_call" previously passed through unchanged; they now return a slimmed data object, which reduces payload size significantly (tests assert < 500 bytes).

Macroscope summarized 22f7a58.

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L 100-499 changed lines (additions + deletions). vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant