[BUG] Cowork MCP client silently drops unknown args and rejects missing-required locally, hiding the server's structured validation error

What's wrong

When Cowork dispatches an MCP tool call, it validates and reshapes the arguments against the tool's published JSON Schema before sending the JSON-RPC request — silently:

1. Unknown/extra properties are stripped with no signal. If the model includes a property not in the published schema (a misremembered field, or one it intends as an alias), the client removes it before dispatch. The model gets no indication an argument was discarded — so a misplaced top-level argument silently degrades the call (e.g. an intended filter is dropped and the query runs unfiltered) instead of erroring.
2. Missing-required is rejected client-side, pre-empting the server. If the (post-stripping) arguments lack a required field, the client rejects locally with a terse message like document_id Required and never dispatches. The server therefore never returns its own structured validation error — which in my server is a rich envelope naming the offending/unknown parameter and pointing to the correct one. The model sees only the terse client string, which names neither the stripped parameter nor any remediation.

Net effect: the model loses both signals it would use to self-correct — that an argument was dropped, and the server's structured guidance.

What should happen

Either resolves it: (a) surface stripped/unknown arguments back to the model (e.g. "ignored unknown argument X" in the result); and/or (b) don't short-circuit on client-side required checks — let the server's structured validation error reach the model. Honoring additionalProperties: false and required fields client-side is defensible; doing it silently and ahead of the server is what removes recovery.

Environment

• Surface: Claude for Desktop (Cowork tab), Claude Code 2.1.156 (Agent SDK 0.3.156), model Opus 4.8, macOS (Darwin 25.5.0), Apple Silicon.
• MCP server: FastAPI + uvicorn, Pydantic v2 (extra="forbid"), tools/list publishes additionalProperties: false, mounted over HTTP/SSE.
• Server-side strict validation verified correct via direct HTTP (returns a structured unknown_parameter envelope); the client never dispatches the call that would surface it.

Steps to reproduce

1. Expose a tool whose schema has additionalProperties: false and a required field (document_id).
2. From Cowork, call it with (a) an extra top-level property not in the schema and (b) document_id omitted.
3. Observe: the extra property is silently removed; the call is rejected locally with document_id Required; server logs show no request arrived.
4. Variant: call with only the unknown property — it's silently dropped with no mention.

Related (not duplicates)

• #56263 and #58747 (silent schema stripping), #32524 (typed params sent as strings) — those concern correctness of schema/serialization; this report is about diagnostic transparency when the client mutates or rejects a call.