Dropbox MCP

Dropbox runs its own remote MCP server at https://mcp.dropbox.com/mcp. It is a fuller product than most vendor MCP servers: twenty-five tools, real write access, and a folder restore that genuinely works. If you compared it to Google Drive MCP and came away thinking they are the same kind of thing, they are not. Dropbox shipped the harder half.

This page covers what the server does, how to connect it, and the two ceilings that decide whether it can be your agents’ working directory or only their document shelf.

The three things people mean

1. Dropbox’s official remote MCP server

The one at mcp.dropbox.com. Dropbox’s own documentation describes it as being in open beta and generally available at the same time, which in practice means you can use it today and the terms say it may change. It speaks Streamable HTTP and authenticates with Dropbox OAuth.

https://mcp.dropbox.com/mcp

2. The Dropbox Dash MCP server

A separate server with a separate endpoint. Dash searches across everything your company has connected to it, not just Dropbox, so it answers a different question: “where is the thing” rather than “read and change this file”. Connecting one does not connect the other. Most people searching for Dropbox MCP want the first server, not this one.

3. Community servers and hosted gateways

Several community implementations exist, including ngs/dropbox-mcp-server in Go, and gateways such as Zapier MCP, Make, Composio and StackOne expose Dropbox through their own endpoints. The gateways add actions and a third party sitting between your agent and your files. Since March 2026 the official server has covered most of what people reached for these to get, so check it first.

What the official server can actually do

Twenty-five tools, and the coverage is broad enough to be worth reading as groups rather than a list:

• Read and browse. ListFolder, GetFileMetadata, GetFileContent, Search, GetUsageAndQuota, WhoAmI.
• Change things. CreateFile, CreateFolder, Copy, Move, Delete.
• Undo things. ListFileRevisions, RestoreFileRevision, RestoreFolder, ListRestoreEvents.
• Share things. CreateSharedLink, ListSharedLinks, GetSharedLinkMetadata, DownloadLink, plus three file-request tools.
• Convert things. GetMarkdown turns PDFs and Word documents into Markdown with OCR for scans, and GetTranscript transcribes audio and video with timestamps.

Credit where it is due, because the comparison usually gets written unfairly. RestoreFolder restores a folder and its subfolders to an earlier point in time, in one call, from an agent. Google’s Drive server has no equivalent and neither do most storage MCP servers. If a bad agent run touched eleven files in a folder, Dropbox can put that folder back. That is the single most important thing a drive can do for agent work and Dropbox built it.

Connecting it

Dropbox supports Dynamic Client Registration for a trusted set of clients: Claude Code, Claude Web, ChatGPT Codex, ChatGPT Web and Cursor. For those, you add the endpoint and approve Dropbox’s OAuth screen, with nothing to register and no keys to paste.

Every other client is more work. You register your own Dropbox app in the App Console, choose its access type, and supply the credentials yourself. Note that access type is close to permanent: Dropbox’s developer guide says changing an app between App folder and Full Dropbox means deleting the app and creating a new one.

Where it stops being a working directory

None of this is a bug. Dropbox is a sync product for people who keep files, and it is very good at that. These are the places where that design and a fleet of agents writing to the same tree pull in opposite directions.

Five megabytes, in both directions

This is the ceiling that decides everything. GetFileContent supports “files up to 5 MB”, and CreateFile creates “a new text-oriented file from inline UTF-8 content up to 5 MB”. Dropbox suggests it is “best suited for documents like notes, markdown, JSON, and source code”, which is an accurate description of the window you are working in.

A 6 MB CSV that an agent needs to change one column in is out of reach through this server. So is a long transcript, a large export, or any binary the agent produced. You can still hand the agent a download link, but then the agent is reading bytes it cannot write back.

Every write is a whole-file rewrite

There is no patch or edit tool. To change one line, an agent reads the entire file, holds it in context, regenerates the whole thing, and sends all of it back through CreateFile. That is fine for a 4 KB note. On a 3 MB document it costs a large fraction of the context window on every pass, and a model that drifts or truncates in the middle of regenerating overwrites the good copy with a shorter one. The version is recoverable. The token spend and the wasted turn are not.

History is a clock, not a ledger

Dropbox version history is time-based and tied to your plan: 30 days on Basic, Plus and Family, 180 days on Professional, Essentials, Business and Standard, and 365 days on Business Plus, Advanced and Enterprise. Two details matter more than the numbers. Upgrading is not retroactive: “your new version history starts the day you upgrade and doesn’t apply retroactively”. And ListFileRevisions “returns up to 100 revisions with the newest revision first”.

A human editing a document produces a handful of revisions a week. An agent writing every few minutes produces a hundred in an afternoon, and from then on the older ones are simply not in the list the agent can see.

The record names the app, not the agent

Dropbox does track applications as actors. The team events API records an actor that can be a user, an application, or other, which is more than Drive offers. Two caveats decide whether that helps you.

First, it is a team API: /team_log/get_events needs a team-linked app with auditing permission, so it is not there on Plus or Professional. Second, and more limiting, the unit of identity is the Dropbox app. Point five agents at one connection and the log shows one actor five times. Distinguishing them means registering five separate Dropbox apps, each with its own OAuth flow, its own credentials and its own fixed access type.

Searching inside files is a Business feature

Search covers “name or content”, but the content half is plan-gated at the API level: Dropbox’s search documentation states that full-text results are returned for Dropbox Business users, and that everyone else gets filename results only. On Plus and Professional, an agent asking “which file mentions this” is really asking “which file is named this”.

Where full text does work, the agent still has to open the file to act on what it found, which puts it back at the 5 MB ceiling. Finding the line is cheap. Reading the file the line is in is the part that costs.

Nothing stops two agents writing the same file

The tool surface has no lock and no conditional write. If two agents call CreateFile on the same path, the second one wins and the first one is never told. The revision is retrievable afterwards, which is a real safety net, but only once somebody notices. There is no way to say “write this only if it is still at the version I read”.

When Dropbox MCP is the right answer

Frequently. It is well built, it is already paid for, and for a large class of work it is the correct tool:

• The files already live in Dropbox and people open them there. Do not move those somewhere else.
• The agent works on documents, notes, Markdown, JSON or source, comfortably under 5 MB.
• You need PDFs, scans or recordings turned into text. GetMarkdown and GetTranscript are genuinely useful and not easy to replicate.
• One agent at a time, or agents on clearly separate folders, so nothing races.
• A human reviews the output before it matters.

If that is your situation, connect Dropbox and stop reading. You do not have a problem to solve.

When you need a drive built for agents

The other shape of work is several agents writing to the same tree, repeatedly, without a person between each pass. Shared plans and notes, datasets that get transformed in place, scratch state that outlives one session, context handed from one agent to the next. There the limits above compound: the file is too big for the pipe, every edit costs a full rewrite, the revision list runs out, and the log cannot tell you which of your agents did it.

Layven is a drive for that case. Same connection method, one config block, different guarantees.

The honest trade runs both ways. Dropbox holds the files your colleagues open, syncs to their laptops, and converts a scanned PDF better than Layven does. Layven does none of that and is not trying to. Layven holds what your agents are working on. Plenty of fleets connect both, which is fine, because an agent can hold two drives at once and the config for each is a URL and a token.

Next

Connecting Layven takes about two minutes in any client: Claude, Claude Code, Cursor, ChatGPT, or any other MCP client. If you are weighing up more than one storage backend, the same treatment of Google Drive MCP covers a server with the opposite problem: it cannot edit an existing file at all, and S3 MCP server covers the build-it-yourself option.