Dropbox (Upload)

Proxy for Dropbox's content.dropboxapi.com host — the one route identos.dropbox cannot reach. Install both connectors against the same Dropbox account for full read/write file access:

• identos.dropbox — metadata, list, search, create/move/copy/delete, and get_temporary_download_link (a 4-hour unauthenticated URL — this is how to read a file's actual bytes).
• identos.dropbox-content (this one) — upload_file, the one operation that genuinely needs Dropbox's other host.

identos.dropbox and identos.dropbox-content both name a scope dropbox:files:write. The gateway does not refuse a token of another connector type whose scope names match a route's scope (see Check the scope and resource). In our run a client_credentials token issued for the identos.dropbox type with dropbox:files:write got 200 from an identos.dropbox-content resource's upload_file, over REST and over MCP. We did not run the reverse direction. dropbox:files:write and calendar:read (Google and Microsoft calendar) are the only scope names that two shipped connectors share.

Why two connectors

Dropbox splits its v2 API across two hostnames: api.dropboxapi.com for JSON RPC calls (metadata, including a get_temporary_link RPC call that hands back a plain download URL), and content.dropboxapi.com for raw request/response bytes (upload takes the file as the literal request body, download returns the literal response body). A managed resource has one fixed upstream base URL, so one manifest can't address both — hence a second connector for the one operation (upload) that has no RPC-side equivalent the way download does via get_temporary_link.

upload_file's request doesn't fit the gateway's normal JSON/form body composition either — Dropbox expects the raw file bytes as the entire body, with the structured arguments (path, mode, autorename, mute) serialized into a Dropbox-API-Arg header instead. The route uses a server-side request_body_composer (dropbox.upload, DropboxUploadComposer.java) to build that shape from the tool's content_base64 + other arguments.

Authentication

This connector declares two modes, user_secret (the default, each user links their own Dropbox access token) and static (one shared token). It has no idp_passthrough mode, which is the default for identos.dropbox. When both connectors use a token, the same token can serve both. See identos.dropbox's README for the full explanation and where to generate a token.

Manifest reference

• ID: identos.dropbox-content
• Version: 1.0.0
• Resource type: urn:connector:identos:dropbox-content
• Capabilities: mcp

Supported auth modes

Type	Details
user_secret	—
static	scheme bearer; setup fields: token_env

Setup fields

ID	Label	Default	Secret?	Notes
upstream_auth.type	Authentication	user_secret	no	user_secret (recommended) has each user link their own Dropbox access token, so actions are attributed to the real user. static uses one shared token for everyone.
token_env	Access token	—	yes	Used only for the static method. A secret holding a Dropbox access token, sent as Authorization: Bearer <token>. / shown when upstream_auth.type == 'static'

Scopes

Scope
dropbox:files:write

Routes

Method	Pattern	Scope	Resource template
POST	/files/upload	dropbox:files:write	dropbox://files

MCP tools

Name	Scope	Description
upload_file	dropbox:files:write	Upload a file's raw bytes to Dropbox, creating or overwriting it at the given path.