I'm reporting a bug in the official Dropbox MCP server (https://mcp.dropbox.com/mcp) that makes it unusable with Anthropic's Claude API (Claude Code, Claude Desktop, and any other Claude client that loads MCP tool schemas).
Whenever the Dropbox MCP server is connected, Claude sessions intermittently fail at the very first API call with:
API Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.N.custom.input_schema: input_schema does not support oneOf, allOf, or anyOf at the top level"}}
The index N varies (10, 24, 88, …) depending on how many other tools are in front of it in the request. The session is completely bricked until the Dropbox connector is disabled — no tool calls can be made, not just Dropbox ones, because Anthropic validates the entire tools array up front.
Root cause:
The list_folder tool exposed by the Dropbox MCP server ships this inputSchema:
{ "type": "object", "oneOf": [ { "type": "object", "additionalProperties": false, "required": ["path"], "properties": { "path": { "type": "string", "pattern": "^(?:|/.*|ns:[0-9]+//.*)$" }, "max_depth": { "type": "integer" }, "max_results": { "type": "integer" }, "object_types": { "type": "array", "items": { "type": "string" } } } }, { "type": "object", "additionalProperties": false, "required": ["cursor"], "properties": { "cursor": { "type": "string" } } } ]}
The intent is clearly "either start a new listing with path, or continue with cursor". But Anthropic's API explicitly disallows oneOf / allOf / anyOf at the top level of a custom tool's input_schema — the top-level must be a plain { "type": "object", "properties": { … } }. This is documented in the Anthropic tool-use spec and is enforced server-side. Reference - https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
So Dropbox's schema is technically valid JSON Schema, but it isn't a valid Anthropic tool schema, and every Claude session that loads it fails.
How to reproduce:
- Connect the Dropbox MCP at
https://mcp.dropbox.com/mcp to Claude Code (or any Anthropic-API client). - Start a session that surfaces
list_folder into the tools array (in practice, almost every session). - The first API call returns 400 with the
input_schema does not support oneOf, allOf, or anyOf at the top level message.
I confirmed this by dumping remoteMcpServersConfig from Claude Code's local session cache — Dropbox is servers[2], and tools[6] is list_folder with the bad schema shown above. Every other tool on the Dropbox server has a valid flat schema; only list_folder is broken.
Suggested fix:
Flatten the schema so the top level is { "type": "object", "properties": { … } } with no oneOf, and enforce the path-or-cursor exclusivity at request-handling time instead. Something like:
{ "type": "object", "additionalProperties": false, "properties": { "path": { "type": "string", "pattern": "^(?:|/.*|ns:[0-9]+//.*)$" }, "cursor": { "type": "string" }, "max_depth": { "type": "integer" }, "max_results": { "type": "integer" }, "object_types": { "type": "array", "items": { "type": "string" } } }, "description": "Provide either `path` to start a new listing, or `cursor` to continue a previous one. Exactly one must be set."}
Then on the server side, return a tools/call error if neither or both are provided. This is the standard pattern other MCP servers use for paginated list endpoints.
Until this is fixed, the Dropbox MCP is effectively unusable for any user of Claude Code / Anthropic's API - connecting it breaks every Claude session, not just Dropbox tool calls. Users currently have no workaround other than disconnecting the Dropbox connector entirely.
Happy to provide a request_id from a failing call if useful.
Thanks!
