Subject: MCP stdio transport corrupts non-ASCII characters (UTF-8 Mojibake) in tool call arguments

DEV TMS AI Studio
1

Product: TMS AI Studio 1.6.0.0 Component: MCP Server / stdio transport Delphi version: Delphi 11

When using TMS AI Studio to implement an MCP server with stdio transport, string parameters passed by the AI client (Claude Desktop) that contain non-ASCII characters — such as German umlauts (ä, ö, ü, ß) — arrive at the tool handler corrupted.

Example: The string "Gehäuse" arrives as "Gehäuse" in the Args array of the tool handler function.

This is classic UTF-8 Mojibake: the UTF-8 byte sequence for ä is 0xC3 0xA4. When these bytes are incorrectly interpreted as Latin-1/Windows-1252, they produce the two characters à (0xC3) and ¤ (0xA4) — which is exactly what we observe.

Root cause

MCP communication over stdio uses JSON encoded as UTF-8. BSTR/WideString in Delphi is UTF-16LE internally. The stdio stream reader in the TMS AI Studio MCP transport layer appears to read the raw UTF-8 bytes and place them into a WideString without first decoding them as UTF-8. Each UTF-8 byte is treated as a Latin-1 character and widened to a UTF-16 code unit, rather than the multi-byte sequence being decoded to the correct Unicode code point.

Steps to reproduce

  1. Create an MCP server using TMS AI Studio with a tool that accepts a string parameter.

  2. Call the tool from Claude Desktop with a parameter value containing a German umlaut, e.g. "Gehäuse".

  3. Inspect the value of Args[n].AsString in the tool handler.

  4. Observed: "Gehäuse" — Expected: "Gehäuse"

With kind regards,

Peter

3

Hi,

Thank you for notifying us. We have applied a fix for this that will be included in the next version of the TMS AI Studio.

regards,