Tool call parses successfully but a string parameter is silently corrupted with an adjacent parameter's boundary tag, correlated with parameter count

Bug Description

An MCP tool call parses and delivers successfully (no "malformed and could not be parsed" error, no retry prompt), but one of its string parameters silently contains a substring resembling a different parameter's boundary tag (<parameter name="...">), even though that literal text was never authored in any parameter's actual content. This is not a harness-level parse rejection, it's silent content corruption inside an otherwise successfully-parsed call, which means it would go completely undetected by any tool/MCP server that doesn't run its own application-level content validation.

Controlled reproduction

A custom MCP server with a write-time content guard rejected a tool call because a string parameter contained <parameter name=. This call had 3 populated string parameters (call them A, B, C).

To isolate the trigger, the identical content for A and B was resent with C simply omitted. That call succeeded cleanly, no corruption, content stored intact. Re-adding C (unchanged content, unchanged A/B) reliably reproduced the failure again.

This rules out two obvious explanations:

• Not raw argument length. A separate, much longer 2-parameter call (~600 words) on the same tool succeeded cleanly earlier the same session. The failing 3-parameter call was shorter (~230 words total) than that successful one.
• Not specific characters/punctuation. A and B's content was byte-for-byte identical between the failing and succeeding calls; only C's presence changed.

The correlate that held across every attempt was the count of populated string parameters on a single call, not their size or content.

What is NOT known

The exact point in the pipeline where the corruption is introduced. Only the content actually received by the downstream tool is observable from this vantage point, not the raw wire format between model generation and the harness delivering the call, so this could be model-generation-side or client-serialization-side. Reporting the correlation, not a root cause.

Environment

• Claude Code (CLI)
• Model: Sonnet 5 (claude-sonnet-5)
• OS: Windows 11 Home (10.0.26200)
• Shell: Git Bash / PowerShell
• Custom MCP server involved (stdio transport), tool schema with 5 optional string parameters, 3 populated in the failing call

Likely related (same general tool-call-argument-corruption family, different surface symptom, visible parse rejection there vs. silent content corruption here): #63879, #70544, #69522

Workaround in place
Avoid populating 3+ substantial string parameters on a single call to the affected tool, consolidate into fewer parameters instead. Not a real fix, just avoidance of the trigger condition observed so far.