MCP connector delivers inconsistently-typed tool schemas: array param intermittently published as string, constrained sampling then makes writes impossible (-32602 Expected array, received string)

Summary

The claude.ai Asana connector (first-party, UUID-named MCP server 1160e6a9-…) intermittently delivers a degraded tool schema for its bulk-write tools (create_tasks, update_tasks): the tasks parameter, which the server validates as an array of objects, is sometimes published to the session typed as a plain string. When the degraded variant is loaded, schema-constrained sampling forces every tool call's tasks value into a JSON-encoded string, so the model cannot emit a valid array no matter what it writes, and the server correctly rejects every attempt:

MCP error -32602: Input validation error: Invalid arguments for tool create_tasks: [
  { "code": "invalid_type", "expected": "array", "received": "string",
    "path": ["tasks"], "message": "Expected array, received string" }
]

The result is an unwinnable retry loop: the agent is told "Expected array, received string," retries with what it believes is an array, and the wire carries a string again. Reads and scalar-param writes (add_comment) are unaffected throughout.

Environment

• Claude Code 2.1.63, macOS desktop app (darwin arm64)
• Asana connector attached via claude.ai connectors (tools surface as deferred mcp__<uuid>__*, loaded via ToolSearch)
• Observed 2026-07-28 and 2026-08-04, in a main session and in a subagent, across different sessions of the same account

Evidence that it is schema delivery, not the model, server, or auth

Reconstructed from local transcripts (~70 Asana write calls, May 25 → Aug 4):

1. The server-side schema is correct and stable. Every rejection is server-side (MCP error -32602) and says expected: "array". Every call that carried a real array across three months was accepted.
2. It flips with no local change. In one session (Jul 28): tasks emitted as string and rejected at 15:41–15:45, then the same tool accepted a real array at 16:26 — same session, same conversation, no restart. On Aug 4: a subagent was string-locked at 07:29 while a sibling main session wrote clean arrays at 07:53.
3. Degradation is per-tool within a single ToolSearch load. In the failing subagent, get_project was delivered correctly typed (a wrong param name was caught by client-side validation before the wire), while create_tasks strings passed client-side validation and died at the server. Same load, same moment: simple schemas intact, complex array-of-objects schemas degraded.
4. Constrained sampling, not model confusion. After the explicit "Expected array, received string" error, the agent's retries still carried strings — including a minimal probe that arrived as {"tasks": "[]"}. A model free to emit JSON would send {"tasks": []} after that error; only a string-typed input schema forces "[]".
5. The healthy variant, captured today from a session where delivery is currently fine: tasks is properly typed ("type": "array", full items schema, min/max). So both variants demonstrably exist in delivery.
6. String-encoding of complex params visibly exists in this connector's schema pipeline. In the currently-delivered healthy schema, create_tasks.tasks[].custom_fields is typed "string" (JSON-encoded map) while update_tasks.tasks[].custom_fields is typed "object" — and the field description itself says: "Some tools expect a nested object; others expect one JSON string containing the same map." The failure mode reported here is exactly what happens when the tasks parameter itself receives that string treatment in one of the delivered variants. The connector also exposes versioned sibling tools (create_task_preview_v4, create_project_preview_v3, search_tasks_preview), consistent with schema variants rolling out.

Related observation: connector availability itself flaps — the same account's session started with no Asana tools in the deferred list at all (select: by exact name returned "No matching deferred tools found"), and the full toolset appeared mid-session later.

Impact

Any agentic session that catches the degraded schema variant is hard-blocked on structured writes to that connector, burns retries on an error it cannot fix, and typically concludes the connector or harness is broken (our sessions independently wrote it up as "the harness stringifies arrays" and "the connector publishes untyped schemas" before the transcript forensics). Teams then build REST fallbacks, which defeats the point of the connector.

Expected behavior

The schema delivered to the session always matches the schema the server validates against — i.e., tasks is always published as array with its items definition, regardless of which delivery path/variant serves the session or subagent.

Workaround

On the first -32602 "Expected array, received string", stop retrying MCP writes for that session (retries are structurally unwinnable under the degraded schema) and fall back to the vendor's REST API directly.