[BUG] Notion MCP connector (both project .mcp.json and claude.ai OAuth connector) triggers 400 input_schema oneOf/allOf/anyOf error in interactive main loop

Preflight Checklist

• [x] I have searched existing issues and this specific reproduction (Notion connector, interactive main loop) hasn't been reported yet
• [x] This is a single bug report
• [x] I am using a recent version of Claude Code (2.1.158; also reproduces on npm latest 2.1.222 metadata check)

What's Wrong?

Connecting to Notion's MCP server — via either connection path below — reliably produces:

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

(N varies by session — connector/tool load order races.)

Reproduced via two independent paths, both hitting the same underlying Notion remote MCP endpoint:

1. Project-level .mcp.json entry: "notion": { "url": "https://mcp.notion.com/mcp", ... } (remote HTTP MCP server).
2. The "claude.ai Notion" account-level OAuth connector (enabled via /mcp in an interactive session), which appears to proxy to the same underlying Notion MCP server.

Why this differs from existing reports (#64113, #63436)

Those two issues (both closed) explain the mechanism precisely: the interactive main loop defers MCP tool schemas via Tool Search, so a malformed schema normally never reaches validation there — only headless (claude -p) and subagent/Workflow spawn paths eagerly forward full schemas and hit the 400.

In our case, the 400 reproduces directly in the interactive main-loop session, immediately after authenticating/enabling the Notion connector (first message of a fresh session, or immediately after /mcp OAuth completes) — no subagent spawn, no headless invocation involved. This suggests either:

• Tool Search deferral isn't applying to this connector for some reason (maybe an eager tool-list fetch happens as part of /mcp auth or session-start connector registration), or
• The Notion server's schema is malformed badly enough that it's hit during connector registration itself, before Tool Search deferral would normally kick in.

Isolation / debugging performed

• Bisected via claude -p "hi" --mcp-config <file with 1 server> --strict-mcp-config, testing servers one at a time: other MCP servers in the same workspace (two separate MongoDB MCP servers) tested clean in isolation; only notion reproduces.
• Reproduces across multiple fresh interactive sessions (not a resume/cache artifact — ruled out via testing disabledMcpjsonServers/enabledMcpjsonServers combinations and starting genuinely new sessions each time).
• Reproduces on both the project .mcp.json remote server config and the separate claude.ai account connector for the same service (Notion), implying the root cause is server-side (Notion's MCP server emitting a non-conformant input_schema), not a Claude Code connection-path issue — but the fact that it hits the interactive main loop at all is the part not explained by the existing closed issues.

What Should Happen?

Either:

1. Claude Code should sanitize/normalize incoming MCP input_schemas (wrap top-level oneOf/allOf/anyOf combinators into a conformant {"type":"object",...} shape) before ever forwarding them to the Messages API, regardless of code path (main loop / headless / subagent) — this is the most general fix per the suggestions in #63436.
2. Failing that, the interactive main loop's Tool Search deferral should also apply during connector registration/auth (/mcp OAuth flow), not just steady-state conversation.

Steps to Reproduce

1. In a workspace with notion configured in .mcp.json pointing at https://mcp.notion.com/mcp, OR with the "claude.ai Notion" connector enabled via /mcp.
2. Start a new interactive session (or send the first message after auth completes).
3. Observe API Error: 400 ... input_schema does not support oneOf, allOf, or anyOf at the top level immediately, with a different tools.N index each time.
4. Disable the Notion connector/server (remove from enabledMcpjsonServers, or disconnect the claude.ai connector) → error stops reproducing.

Claude Model

Not model-specific (request-level tool-schema validation, as noted in #63436)

Is this a regression?

Unknown — first observed in this workspace within the last few sessions.

Claude Code Version

2.1.158

Platform

macOS (darwin 25.6.0)

Related Issues

• #64113 (headless-only reproduction, different code path)
• #63436 (subagent-spawn-only reproduction, different code path)
• #56174, #44788, #40075, #35901, #4886 (same class of error, connector unidentified in those reports)