MCP tool call drops empty-string argument value, producing invalid JSON

Bug report draft — for review before filing

Repo: anthropics/claude-code
Suggested title: MCP tool call drops empty-string argument value, producing invalid JSON

Body:

Claude Code version: 2.1.241
Platform: Windows 11, VS Code extension (native) and console-mode CLI, both reproduce

Summary

When Claude constructs a tool call for an MCP tool whose input schema has an optional
string parameter, and the intended value is an empty string (""), the client's own
tool-call JSON construction sometimes drops the value token entirely instead of emitting
"". This produces invalid JSON — a key followed by a colon with nothing after it — which
is then correctly rejected by Claude Code's own input validator before the call ever
reaches the MCP server.

Reproduction

1. Connect an MCP server exposing a tool with an optional string parameter typed

["string", "null"] in the tool's JSON schema (in our case, an internal ticketing
system's "update record" tool, with a couple of different optional string fields).

1. Ask Claude to call that tool with the parameter set to an empty string (e.g. "clear

this field").

1. The tool call fails with an error resembling:

``
InputValidationError: <tool> was called with input that could not be parsed as JSON.
You sent (first N of N bytes): {"id": "REC123", "someField": }
Common causes: unescaped backslashes in file paths (use / or \\), unescaped control
characters, or truncated output. Retry with valid JSON.
``

1. Note the payload: "someField": with nothing between the colon and the closing

brace — not even "". This is a malformed-at-construction-time payload, not a
transmission or escaping issue.

Confirmed not server-side

We verified the receiving server handles a genuine empty string correctly: a direct HTTP
call (bypassing Claude Code entirely) with a real "" value for the same field succeeded
and cleared the field as expected. The failure is isolated to Claude's own construction of
the tool-call arguments JSON.

Reproduced deterministically

6 consecutive attempts, across two unrelated string parameters on the same tool, all
produced the identical malformed-JSON shape. Not a one-off token-sampling glitch tied to
one field name.

Impact

Any MCP tool that uses an empty string as a meaningful "clear this value" signal (as
opposed to omitting the parameter, which typically means "leave unchanged") cannot be
reliably invoked that way from Claude Code. Workaround on our end is to avoid needing a
real empty string at all (e.g. accept a sentinel value instead) — but this seems like it
would affect any MCP server designed around empty-string semantics.