DropboxContent Sources and Storage
What Arrives in Dropbox Gets Indexed and Kept
Dropbox is file sync and sharing, and it is often where material from outside the organization first lands: a claimant's photos, an outside firm's documents, a contractor's recordings. Dropbox publishes its own MCP server, and AI Intelligence Hub connects to MCP servers as a client, so an agent works against those folders with configuration rather than development. Pulling the folders into the library on a schedule is the other path, and it is built per engagement. Dropbox keeps doing what it does now.
What you can do together
- Ask AI Intelligence Hub a question that spans Dropbox folders and the library at once, reaching Dropbox through its own server rather than a connector built for it.
- Put a workflow on a Dropbox folder so what arrives is read, summarized and routed, with a person approving anything that writes back or sends.
- Have the folders ingested into the library instead, where the material needs transcription, retention and a custody record of its own. That path is scoped per engagement.
- Get an answer whose library citations were retrieved under your own identity, so nothing you could not open was a candidate for it.
- Reach Dropbox from a workflow through its MCP server when a step needs something from Dropbox itself.
How it connects
Dropbox publishes an MCP server and the platform is the client. The connection is configured once with a name, the server URL, the transport and the headers carrying its credential, and the server's tool list is fetched when the connection binds rather than coded in. A workflow reaches one named tool through an MCP node; an agent is handed the whole list and chooses as it works. The connection carries the credential it is configured with, so what an agent can read in Dropbox is bounded by what that credential is granted there.
Bringing folders into the library on a schedule is a different path, and it is built per engagement rather than prebuilt. It would run on the ingestion connector architecture that already carries Google Drive, OneDrive and SharePoint: the pull scoped by an extension allowlist and excluded folders, the hierarchy preserved or flattened as configured, the source left in place, moved or deleted after each file lands, and runs on a schedule rather than on Dropbox events.
Nothing flows the other way. Dropbox is not a storage provider, so the library's copy lives on the platform's own storage, and the connector writes nothing back beyond the configured move or delete. Dropbox sharing settings do not carry across: who can open an ingested item is decided by the portal's own roles.
DropboxContent Sources and Storage
A scenario
- SetupAn administrator adds Dropbox's MCP server to AI Intelligence Hub once: name, URL, transport, and a credential scoped to the
Claims intakefolder. The tool list appears without anything being coded. - 09:10An adjuster drops a claimant's photos and a recorded statement into the claim's subfolder.
- 09:15A workflow the unit built on the visual canvas reads the folder through the server, drafts a summary of what arrived, and hands it to a senior adjuster to approve before it is attached.
- Later that morningThe adjuster asks what the claimant said about the time of the collision. The agent reads the Dropbox folder through the server and the unit's earlier recorded statements from the library, and cites both. The library half of that retrieval ran under her identity, so material she may not see was never a candidate.
- Later stillThe carrier decides closed claims need retention and a custody record of their own, so the recorded statements are scoped into an ingestion connector built for that, and the working files stay in Dropbox.
What stays where
Dropbox remains the intake point
Outside parties keep sharing into it, and the team keeps working there. The connection reads through Dropbox's own server, and the credential it carries is the boundary on what it can reach.
AI Intelligence Hub reads, and writes back only what a tool call is authorized to write
Dropbox sharing and folder permissions are not changed. Where an ingestion connector is built, the source file is left, moved or deleted according to the post-ingestion action set for it.
Nothing is replaced
Dropbox holds what it always held, and no second copy exists unless an ingestion connector is built to make one.
Processing runs where the platform runs
Transcription, indexing and the assistant run on the platform's infrastructure, as SaaS, in your own cloud or on your own servers, with the library's copy on the storage provider configured for the portal.
Products and solutions
Next step
See it on your own Dropbox instance.
We will show the connection made, the data moving and the output, then size it for your deployment.
Contact VIDIZMO
sales@vidizmo.ai
+1 571-969-2180
vidizmo.ai