[BUG] Regression of #32524/#24599: MCP tool params (number/boolean/object) serialized as strings — desktop app, started July 9 ~7:20 PM ET

Open 💬 1 comment Opened Jul 10, 2026 by jjustinmorgann

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

Since the Claude desktop app update/restart at ~7:20 PM ET on July 9 (macOS, build 1.20186.0), all MCP tool parameters that are numbers, booleans, or objects arrive at remote (claude.ai) connectors as strings. Servers with strict validation reject them:

MCP error -32602: Input validation error: ... "expected": "number", "received": "string"

This is a recurrence of #24599 (Feb) and #32524 (Mar), both previously fixed.

Repro

  1. Desktop app, any claude.ai remote connector with a typed schema (reproduced on Attio, Linear, Windsor.ai).
  2. Call e.g. Attio list-records with limit: 2 (number) → fails "Expected number, received string".
  3. Same call with limit omitted (string-only params) → succeeds.
  4. Same call with limit: 3 from claude.ai in the browser → succeeds, returns exactly 3 records.

Scope

  • Numbers, booleans, and objects all affected (limit, includeRelations: true, Attio values object, Windsor execute_action params).
  • String and array params pass through fine.
  • Browser (claude.ai) unaffected → desktop client serialization layer.
  • Worked correctly all day July 9 until the ~7:20 PM ET update.

Impact

All connector write operations requiring structured params are blocked in the desktop app (CRM record creation, ad-platform actions), across every connector/account we run.

What Should Happen?

Tool parameters should be delivered to MCP servers with their JSON types intact, exactly as the tool's inputSchema declares them: limit: 2 should arrive as the number 2 (not "2"), includeRelations: true as a boolean, and Attio's values as a JSON object. Calls that validate and succeed on claude.ai in the browser should behave identically in the desktop app — as they did before the July 9 evening update, and as restored by the fixes to #24599 and #32524.

Error Messages/Logs

Steps to Reproduce

  1. Open the Claude desktop app on macOS (build 1.20186.0, updated July 9 ~7:20 PM ET) with any claude.ai remote connector that has strictly-typed tool schemas enabled (reproduced on Attio, Linear, and Windsor.ai connectors).
  2. Ask Claude to call a connector tool with a number parameter — e.g. Attio list-records with object: "companies" and limit: 2.
  3. Observe the call fail with:

MCP error -32602: Input validation error: Invalid arguments for tool list-records: [{"code": "invalid_type", "expected": "number", "received": "string", "path": ["limit"], "message": "Expected number, received string"}]

  1. Repeat the identical call with limit omitted (string params only) — it succeeds, confirming auth/connectivity are fine.
  2. Repeat the identical call (limit: 3) on claude.ai in a browser with the same connector and account — it succeeds and returns exactly 3 records.
  3. Variants: boolean params (Linear get_issue with includeRelations: true) and object params (Attio create-record values, Windsor.ai execute_action params) fail the same way on desktop; even a bare empty object {} fails with "expected object, received string".

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

build 1.20186.0

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗