[BUG] Cowork artifact window.cowork.callMcpTool fails with 'Tool call failed: 400' for every connector

Environment

• Claude Desktop / Cowork mode, macOS (MacBook Pro 13" M1, 16GB RAM)
• First observed: 2026-07-03, still present 2026-07-04

Description

Inside a Cowork artifact, window.cowork.callMcpTool(name, args) fails with Tool call failed: 400 for every call, regardless of which MCP connector or tool is targeted, including a call with zero arguments to an unrelated connector. The failure is not specific to one connector, one tool, one argument, or one file path.

What I ruled out before filing this

• Connector permissions: all read-only tools set to "Always allow" in Settings > Connectors > Enabled, no change.
• File path: switched from a path containing Cyrillic characters/spaces/tilde to a plain ASCII path, no change.
• Extra parameters: removed a non-essential length argument, no change.
• Restarting Cowork / the target app (Obsidian), no change.
• Full quit and relaunch of Claude Desktop (Cmd+Q, not just closing the window), no change.
• Retrying with delay (ruled out a transient/rate-limit cause), same error every time, not transient.

Reproduction

Built a minimal diagnostic artifact that fires 5 different callMcpTool calls across 2 different connectors:

1. Desktop_Commander.read_file on the original (Cyrillic) path
2. Desktop_Commander.read_file on a simplified ASCII path
3. Desktop_Commander.get_file_info on the ASCII path
4. Desktop_Commander.get_config (zero arguments)
5. scheduled-tasks.list_scheduled_tasks (a completely different connector)

All 5 calls failed identically with Tool call failed: 400.

Isolating the bug

Direct MCP tool calls made from the Claude conversation itself (not through the artifact's window.cowork.callMcpTool bridge) work normally, e.g. Desktop_Commander.get_file_info and read_file against the same paths succeed instantly when called by Claude directly, and a scheduled task that calls the same connector server-side also completes successfully. This points to the bridge between the rendered artifact (browser-side window.cowork) and the MCP layer specifically, not the connectors or the account's MCP permissions.

Impact

Any artifact that depends on live connector reads for its data (status dashboards, trackers) is stuck falling back to a static/baked-in snapshot and cannot refresh, with no way to recover from within the artifact itself.

Request

Would appreciate a look at what changed around 2026-07-03 for the callMcpTool bridge specifically (vs. direct MCP calls from the assistant), since that's the one path that's broken.

Related, but distinct

#65830 is the same general area (Cowork MCP connector path) but a different failure: HTTP 500 there vs 400 here, intermittent/self-resolving there vs persistent since 2026-07-03 here, a custom OAuth connector there vs built-in connectors (Desktop Commander, scheduled-tasks) here, and a scheduled task there vs a live artifact's window.cowork.callMcpTool bridge here. Flagging in case of a shared root cause, filing separately since symptoms differ.