MCP tool response mangles UTF-8 as Latin-1 (double-encoding on re-echo)

Summary

When an MCP tool's response echoes back a string that contained a non-ASCII UTF-8 character (e.g. en-dash –, U+2013), the character comes back mojibake'd — displayed as if its UTF-8 bytes were Latin-1 / Windows-1252. If Claude then re-includes that mojibake in a subsequent tool call whose response echoes it again, the corruption compounds (double-encoding).

Observed with the mcp__gworkspace__updateGmailDraft tool but the failure mode looks like generic byte/charset mishandling in the MCP response path, not something specific to Gmail.

Repro

1. Call a Gmail draft tool (createGmailDraft or updateGmailDraft on the zueai/google-workspace-mcp server) with a subject containing an en-dash:

``
Test subject with en-dash – hello world
``

1. The tool's response echoes the subject back. Instead of – (U+2013, UTF-8 bytes E2 80 93), it prints – — those same bytes reinterpreted as Latin-1.

1. If you then call an update tool that echoes the (now mangled) subject again in its response, the mangling compounds:

• Original: –
• After 1 round-trip: –
• After 2 round-trips: –

The stored Gmail draft itself is correct — the corruption is only in the tool response text shown back to the model/user. But because Claude reads that response as ground truth for the current draft state, subsequent operations can propagate the mangling.

Impact

• Any subject / body / filename containing a smart quote, em-dash, en-dash, non-breaking space, accented letter, or any non-ASCII character will render as gibberish in tool responses.
• On multi-step draft editing (create → update → confirm), the gibberish compounds, making it look increasingly worse to the user each turn even when the underlying Gmail state is fine.
• Users lose trust in whether the actual message will be sent correctly.

Expected behavior

Tool responses should be UTF-8 throughout the pipeline. A subject containing – should be echoed back as –, not –.

Suspected location

Somewhere between the MCP server's response serialization and Claude Code's parsing of it, bytes are being decoded with the wrong codec (looks like Latin-1 / Windows-1252 instead of UTF-8). Given the double-encoding on re-echo, the same misdecoding happens on both the outbound and return paths.

Environment

• Claude Code CLI, model claude-opus-4-7
• MCP server: zueai/google-workspace-mcp (Gmail tools)
• macOS Darwin 25.5.0, zsh, UTF-8 locale

Workaround

None inside a conversation. Users can pre-normalize input to ASCII (– → -, " → ", etc.) but that defeats the purpose of Unicode support.