[BUG] Cowork/Desktop strips property-level oneOf from MCP tool schemas and JSON-stringifies arguments for affected fields - regression in 1.21459.0 breaks Mailtrap MCP send-email (extends #18260)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

The Mailtrap MCP server declares its send-email / send-sandbox-email to and from parameters as a property-level oneOf union (plain email string, or {email, name?} object, or an array of those). In Claude Desktop Cowork sessions, two compounding behaviors break every call that uses the documented non-scalar shapes:

1. Schema stripping (model-visible). The tool schema surfaced inside the session has the oneOf node replaced by an empty schema - "to": {}, "from": {} - type, items, and description all lost. Sibling fields declared as plain typed arrays (cc, bcc: type: array) survive sanitization intact.
2. Argument stringification for the affected fields. Array/object arguments in the schema-stripped fields arrive at the MCP server as JSON-encoded strings: an object array parses server-side to zero recipients, and a string array reaches the Mailtrap REST API as a single literal JSON-text address. Plain scalar strings pass through intact.

The MCP server's code is correct (v0.4.3 source: normalizeToRecipients / normalizeAddressList handle all declared shapes; no commits to mailtrap/mailtrap-mcp since 2026-06-24). The corruption happens between the model's tool call and the server. Net effect: the tool's documented multi-recipient and display-name forms are unusable, and scheduled tasks depending on the connector fail their primary notification channel.

Environment

• Claude Desktop for Windows (MSIX/windowsStore), Cowork mode
• Regression pinned by updater log: last known-good app 1.20186.1; first failing app 1.21459.0 (auto-updated 2026-07-14 23:18 ET)
• MCP server: Mailtrap MCPB desktop extension v0.4.3 (github.com/mailtrap/mailtrap-mcp)
• Reproduced across models (Fable 5, Opus 4.8) and session types, including scheduled-task sessions, on both the sandbox and production send paths

Relationship to existing issues (why this is not a pure duplicate)

• #18260 (open) covers the serialization symptom for $ref/oneOf params, observed since at least CLI v2.1.7 (months ago). This report adds two elements not documented there: (a) the model-visible schema mutation - oneOf stripped to {} before the model ever sees the tool contract, so the model cannot even know the correct shapes; and (b) a version-pinned regression - this exact connector and field worked on app 1.20186.1 and fails from 1.21459.0 (details in Error Messages/Logs below).
• #59227 / #22394 (both auto-closed as duplicates of #18260) describe the same wire-level stringification; #59227 traced it into @anthropic-ai/claude-agent-sdk.
• Possibly related recurrence on 2026-07-15 (first run under 1.21459.0): the same connector's tools were connected but undiscoverable via ToolSearch for an entire scheduled-task session, then surfaced later in the same session - same symptom class as #57033.

Additional context

Vendor (Mailtrap) has been notified with the same evidence and may follow up through MCP registry partner channels. Full reproduction transcripts, message IDs, sandbox message headers, and updater log excerpts available on request.

What Should Happen?

Either the property-level oneOf schema is preserved so the model sees the real tool contract, or - at minimum - tool arguments are passed to the MCP server byte-for-byte as the model produced them (native JSON arrays/objects per the MCP spec, CallToolRequestParams.arguments as Record<string, unknown>), regardless of how the schema was sanitized for display.

Concretely: to: [{"email": "user@example.com"}] should arrive at the server as a native array of objects and the email should send - as it did on app 1.20186.1.

Error Messages/Logs

# Declared schema (MCP server v0.4.3 source):
"to": { "oneOf": [ {"type":"string","format":"email"}, {"type":"object","properties":{"email":{...},"name":{...}},"required":["email"]}, {"type":"array","minItems":1,"items":{...same union...}} ] }

# Same schema as surfaced inside the Cowork session (oneOf stripped):
"send-email": { "properties": { "to": {}, "from": {}, "cc": {"type":"array","items":{}}, "bcc": {"type":"array","items":{}}, "subject": {"type":"string"}, ... } }

# Verbatim results for repro steps 4-7 (2026-07-16, app 1.21459.0):
step 4  to: [{"email":...,"name":...}]  -> Failed to send sandbox email: Provide at least one recipient via 'to', 'cc', or 'bcc'
step 5  to: ["user@example.com"]        -> Failed to send sandbox email: address is invalid in 'to' 0
step 6  to: "user@example.com"          -> Email sent successfully. Status: Success
step 7  scalar to + object cc           -> Success; received headers:  cc: "User Two <user2@example.com>"

# Regression window (Mailtrap delivery log, same connector, daily scheduled sends):
2026-07-13T17:47:22Z  Scheduled Task Execution Audit Report  -> delivered   (app 1.20186.1)
2026-07-14T09:07:41Z  Scheduled Task Execution Audit Report  -> delivered   (app 1.20186.1)
2026-07-15 onward     scheduled sends fail at argument validation; no log entries (app 1.21459.0)

# App version timeline (Claude Desktop main.log, times ET):
2026-07-13 13:43  Starting app { appVersion: '1.20186.1' }
2026-07-14 12:13  Starting app { appVersion: '1.20186.9' }   (no Mailtrap sends observed on this build)
2026-07-14 23:18  [updater] Version changed since last launch: 1.20186.9 -> 1.21459.0
                  [updater] MSIX detected: windowsStore=true, exe=C:\Program Files\WindowsApps\Claude_1.21459.0.0_x64__pzs8sxrjxfjjc\app\claude.exe
2026-07-15 05:09  first failing scheduled run (app 1.21459.0)

Steps to Reproduce

1. Install the Mailtrap MCPB desktop extension (v0.4.3) from the Claude connector directory; configure an API token and a verified sending domain (a sandbox inbox is enough for the sandbox reproduction).
2. Open a Claude Desktop Cowork session (app 1.21459.0) and load the send-email / send-sandbox-email tools via ToolSearch.
3. Inspect the loaded schema: to and from appear as {} (oneOf stripped); cc/bcc retain type: array.
4. Call send-sandbox-email with to: [{"email": "user@example.com", "name": "User"}], any subject/text -> fails (zero recipients).
5. Call it with to: ["user@example.com"] -> fails (invalid address at index 0).
6. Call it with to: "user@example.com" (plain scalar string) -> succeeds.
7. Control test: scalar to plus cc: [{"email": "user2@example.com", "name": "User Two"}] -> succeeds, and the received sandbox message headers show the cc object survived intact - the identical object is preserved in the typed-array field and destroyed in the schema-stripped field.
8. Repeat steps 4-6 with production send-email - same pattern.

Verbatim error and response text for steps 4-7 is in Error Messages/Logs below.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Version 1.20186.9

Claude Code Version

Version 1.21459.3 (e0f338)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

• Claude Desktop for Windows (MSIX), Cowork mode, current as of 2026-07-16
• MCP server: Mailtrap MCPB desktop extension v0.4.3 (github.com/mailtrap/mailtrap-mcp)
• Reproduced across models (Fable 5, Opus 4.8) and session types, including scheduled-task sessions