Subagent/Workflow creation forwards raw MCP tool schemas → 400 on connector tool with top-level oneOf/anyOf/allOf

Bug: subagent/Workflow creation forwards raw MCP tool schemas → 400 when a connector tool has a top-level oneOf/anyOf/allOf

Claude Code version: 2.1.156
Platform: macOS (darwin 25.3.0)
Model: Claude Opus 4.8, 1M-context variant (claude-opus-4-8[1m]) — main session and inherited by subagents. (Note: the 400 is request-level tool-schema validation, so it is model-independent; reporting for completeness. This model does support tool_reference/Tool Search, which is why the main loop is unaffected.)
Auth: Claude.ai subscription (so claude.ai connectors are loaded)

Summary

When a claude.ai account connector is connected and exposes a tool whose input_schema is a top-level oneOf/anyOf/allOf (common output of zod z.union(...) at the schema root), spawning any subagent that inherits MCP tools fails with:

API Error: 400 tools.137.custom.input_schema: input_schema does not support oneOf, allOf, or anyOf at the top level

The failure is at subagent creation time, so the subagent never runs. This affects the built-in Explore, Plan, and general-purpose subagents, anything spawned via the Agent/Task tool with broad tool access, and the Workflow tool's agents.

Why this is asymmetric (main loop works, subagents don't)

• The main conversation uses MCP Tool Search (enabled by default), which defers MCP tool schemas — they are not sent in the request up front, so a malformed connector schema never reaches tool-schema validation.
• Subagent creation instead forwards the full resolved tool list inline (the subagent "inherits the internal tools and MCP tools available in the main conversation by default"). A single tool whose input_schema violates the Anthropic tool-schema constraint causes the entire tools array in the spawn request to be rejected — so no subagent of that type can be created at all.

Reproduction

1. Auth with a Claude.ai subscription and connect a connector whose MCP tools/list includes a tool with a root-level union input_schema (observed with the Brex/Mercury-style connectors, whose schemas are zod-derived and use anyOf/allOf/$ref).
2. Confirm the main loop works normally (Tool Search defers the schemas).
3. Spawn a subagent that inherits MCP tools — e.g. the built-in Explore or Plan, or Agent(subagent_type: "general-purpose", ...).
4. The spawn fails with the 400 above. It reproduces deterministically for every such subagent in every session while the connector is connected.

Impact

• Subagents and Workflows are completely unusable in any session where a connector with a non-conformant tool schema is present — which silently breaks core workflows (research fan-out, plan-mode exploration, multi-agent orchestration).
• Users cannot fix it from their side cleanly:
• Connector tool schemas are account-managed and not user-editable.
• Built-in subagents (Explore/Plan/general-purpose) cannot be overridden by name (the precedence table omits built-ins).
• permissions.deny only blocks tools at call time — it does not remove them from the request, so it does not prevent the schema-validation 400.
• The only working workaround is the blunt ENABLE_CLAUDEAI_MCP_SERVERS=false, which disables all connectors (losing legitimate connector use in the main loop).

Suggested fix (any one of these)

1. Apply Tool Search deferral to the subagent tool list too, so subagents send tool references rather than full MCP schemas up front — matching main-loop behavior. (Preferred — fixes the class of problem, not just this schema shape.)
2. Sanitize/normalize MCP input_schemas before forwarding to the Messages API (e.g. wrap a top-level combinator in an object, or coerce to the documented {"type":"object", ...} form).
3. Fail soft, not hard: if a tool's schema is non-conformant, skip that one tool and emit a warning naming the offending server + tool, instead of 400-ing the whole subagent spawn. The current error names only an opaque array index (tools.137), which is very hard to trace back to a specific connector/tool.

Notes

• Even short of a full fix, a clearer error (naming the server + tool, not just tools.<index>) would save significant debugging time.
• Please search existing issues for duplicates before filing (terms: "input_schema does not support oneOf", "subagent MCP schema 400", "top level oneOf anyOf allOf"). There appear to be related reports about strict tool-schema validation introduced in recent versions.