SILO-MCP

A self-hosted MCP server that moves files between your filesystem and cloud storage — nine platforms, one tool surface. Upload, download, list, search, delete, generate share links, and copy filesdirectly from one cloud to another, without giving an LLM raw filesystem access or a bag of platform-specific credentials to juggle.

It's not "local-first" — the files live in the cloud and every operation talks to a remote provider API. Whatstayslocal is the part that matters for trust: the server runs as a subprocess on your machine, your credentials sit in the OS keyring (never in the cloud, a config file, or a tool-call argument), and the transfer audit log is a local SQLite file.

Document stores:Dropbox · Google Drive · OneDrive · Box · Google Photos (upload-only) · Yandex DiskObject stores:S3-compatible (AWS S3, Cloudflare R2, MinIO) · Google Cloud Storage · Azure Blob Storage

- Copy a file directly from one cloud to another— "copy my Dropbox/photosfile to my S3 bucket", "migrate this Drive file to OneDrive" — in a single tool call, no manual download-then-upload. The one thing a single-vendor storage integration structurally can't do.
- Move files in and out of cloud storage— "uploadreport.pdfto Dropbox", "downloadnotes.txtfrom Google Drive so I can use it" — across all nine platforms with one set of tools.
- Browse and searchyour document stores by folder or query, and list object-store buckets by key prefix.
- Generate shareable linksto a file — presigned/signed URLs on the object stores and Box (with expiry), platform share links on the rest.
- Bridge to other MCP servers— adownload_filehere lands a local path you can hand straight to another server (e.g. a social-posting server'smedia_paths).
- Keep a local audit trail— every upload, download, delete, and share link is recorded in a local SQLite log you can query withlist_transfers.

All of it runs through your MCP client in natural language — seeExample workflows.

Quick start:pip install -e .→ addsilo-mcpto your MCP client config →silo-mcp-accounts add dropbox --label personal→ ask your client to list your Dropbox files. Full steps inInstallationandAdd accountsbelow.

- What can you do with Silo MCP?
- Why
- Architecture
- Requirements
- Installation
- Configure your MCP client
- Supported clients
- Using with Ollama
- Add accounts
- Example workflows
- Tools
- Supported platforms & tools
- Setup friction and credential shape per platform
- Path safety
- Platform-specific notes
- Safety
- Security
- Testing
- Troubleshooting
- Related
- License

flowchart TB subgraph Client["MCP Client"] direction LR CD["Claude Desktop / Code<br/>(stdio)"] OL["Ollama bridge<br/>(streamable-http / SSE)"] end subgraph Silo["Silo MCP Server (server.py)"] direction TB Tools["Tool surface<br/>upload_file · download_file · list_files<br/>search_files · delete_file · create_share_link"] Paths["paths.py<br/>upload/download root containment"] Registry["stores/registry.py<br/>resolve(platform, account)"] Accounts["accounts.py<br/>credential storage + OAuth refresh"] History[("db.py<br/>SQLite transfer log")] end subgraph Backends["FileStore implementations"] direction LR Doc["Document stores<br/>Dropbox · Drive · OneDrive<br/>Box · Photos · Yandex Disk"] Obj["Object stores<br/>S3-compatible · GCS · Azure Blob"] end FS[("Local filesystem<br/>upload/download roots")] Cred[("OS credential store<br/>Windows / macOS / Linux keyring")] CD --> Tools OL --> Tools Tools --> Paths --> FS Tools --> Registry Registry --> Doc Registry --> Obj Registry --> Accounts --> Cred Tools --> History

Every tool call resolves a(platform, account)pair to aFileStoreimplementation and a credential fromaccounts.py, checks any local path against the upload/download roots, executes against the real platform API, and logs the result — the same shape regardless of which of the nine backends is on the other end.

- Python 3.11+
- An OS credential storekeyringcan use (Windows Credential Manager, macOS Keychain, or a Secret Service provider on Linux) — credentials are never written to disk in plaintext or passed through an MCP tool call.

git clone https://github.com/gouthamkallempudi/silo-mcp.git cd silo-mcp python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\Activate.ps1 pip install -e .

Object-store SDKs are optional extras — only install what you need:

pip install -e ".[s3]" # AWS S3 / Cloudflare R2 / MinIO pip install -e ".[gcs]" # Google Cloud Storage pip install -e ".[azure]" # Azure Blob Storage pip install -e ".[all]" # all three

A core install (no extras) covers Dropbox/Drive/OneDrive/Box/Google Photos/Yandex Disk with no dependency beyondhttpx— the server degrades gracefully if an object-store SDK isn't installed rather than failing to start.

Add to your client's MCP config (e.g. Claude Desktop'sclaude_desktop_config.json, or Claude Code's.mcp.json):

{ "mcpServers": { "silo-mcp": { "command": "silo-mcp" } } }

silo-mcpmust resolve onPATHinside the environment your client launches the server from — if you installed into a virtualenv, pointcommandat that venv'ssilo-mcpexecutable directly (e.g./path/to/silo-mcp/.venv/bin/silo-mcp) instead of relying on shell activation.

Defaults tostdio, what every desktop MCP client (Claude Desktop, Claude Code, Cursor, etc.) spawns as a subprocess — no network port opens. For a client that can't spawn a local subprocess and needs to reach the server over HTTP instead (seeUsing with Ollamabelow), set:

SILO_MCP_TRANSPORT=streamable-http SILO_MCP_HOST=127.0.0.1 SILO_MCP_PORT=8000 silo-mcp

[!WARNING] This server has no built-in auth for HTTP mode — don't bind it to0.0.0.0or expose it past localhost without putting a reverse proxy with auth in front of it, since every tool call reaches your cloud storage accounts.

Any MCP client that can launch a local stdio server works — the server uses only standard MCP tool calls, no client-specific features. Verified and expected-to-work clients:

[!TIP] Ifsilo-mcpisn't on the launching shell'sPATH(common with virtualenvs), setcommandto the venv's executable directly, e.g.C:\\path\\to\\silo-mcp\\.venv\\Scripts\\silo-mcp.exeon Windows or/path/to/.venv/bin/silo-mcpelsewhere.

Ollama doesn't speak MCP natively — it needs an MCP client in the loop that turns Ollama's tool-calling into MCP tool calls, the same role Claude Desktop/Code play for Claude. This server doesn't ship that bridge (kept out of scope to stay a plain server package), but any MCP-aware Ollama client works once you point it at streamable-http instead of stdio:
- Start the server in HTTP mode:SILO_MCP_TRANSPORT=streamable-http silo-mcp.
- Point your Ollama-side MCP client athttp://127.0.0.1:8000/mcp.
- Use a tool-calling-capable model (e.g.llama3.1,qwen2.5) — Ollama only routes tool calls for models that support thetoolsAPI field.

Credentials are added via a CLI with hidden input, never through an MCP tool call, and stored in your OS credential store:

silo-mcp-accounts add dropbox --label personal silo-mcp-accounts add google_drive --label personal silo-mcp-accounts add onedrive --label personal silo-mcp-accounts add box --label personal silo-mcp-accounts add google_photos --label personal silo-mcp-accounts add yandex_disk --label personal silo-mcp-accounts add s3 --label personal silo-mcp-accounts add gcs --label personal silo-mcp-accounts add azure_blob --label personal silo-mcp-accounts list

These four platforms need arefresh_tokenbeforesilo-mcp-accounts addwill accept them — and getting thefirstone requires a one-time browser authorization, not just a client_id/secret pair. Register an app on each platform's developer console, then run:

silo-mcp-accounts oauth google_drive --label personal silo-mcp-accounts oauth google_photos --label personal silo-mcp-accounts oauth onedrive --label personal silo-mcp-accounts oauth box --label personal

This opens your browser to the platform's consent screen, listens onhttp://localhost:8765/callbackfor the redirect, exchanges the code for a refresh_token, and stores the account — no need to runaddafterward.

- Google (Drive + Photos share one app):Google Cloud Console→ new project → APIs & Services → enable theGoogle Drive APIandPhotos Library API→ OAuth consent screen (External is fine for personal testing, add yourself as a test user) → Credentials → Create OAuth client ID → typeDesktop app. Desktop-app clients accept anyhttp://localhost:<port>redirect without pre-registering it, so no redirect URI setup needed.
- OneDrive:Azure Portal→ App registrations → New registration → platformMobile and desktop applications→ add redirect URIhttp://localhost:8765/callbackexactly (Azure requires an exact match). API permissions → Microsoft Graph → addFiles.ReadWriteandoffline_access(delegated). Certificates & secrets → new client secret.
- Box:Box Developer Console→ Create new app →Custom App→User Authentication (OAuth 2.0)→ under Configuration, set Redirect URI tohttp://localhost:8765/callbackexactly (Box also requires an exact match) and check the scopes you need (Read/write files).

Yandex Disk is a static token like Dropbox — norefresh_token, so it's not part of thesilo-mcp-accounts oauthbootstrap flow above. Its OAuth app config uses animplicit grant: the token comes back directly in the browser, no code-exchange step to script.
- oauth.yandex.com→Create app(or reuse an existing one).
- UnderPlatforms, checkWeb servicesand set the redirect URI tohttps://oauth.yandex.com/verification_code— Yandex's own built-in page that just displays the token, no local listener needed for this one.
- UnderPermissions, grant Disk access:cloud_api:disk.readandcloud_api:disk.write(orcloud_api:disk.app_folderinstead ofdisk.writeif you want to scope it to an app-specific folder rather than the whole disk).
- Save the app and note itsID.
- Visithttps://oauth.yandex.com/authorize?response_type=token&client_id=<your-app-id>in a browser, approve access — the token is shown directly on the redirected page.
- silo-mcp-accounts add yandex_disk --label personal, paste the token.

Import file— copy the template, fill in real values, import in one shot.silo-accounts.example.yamlat the repo root has an entry for all nine platforms with the exact field names each one needs and a comment on where to get each value:

cp silo-accounts.example.yaml silo-accounts.yaml # edit silo-accounts.yaml with real values, delete platforms you don't use silo-mcp-accounts import silo-accounts.yaml

SILO_MCP_CRED_DROPBOX_ACCESS_TOKEN=sl.xxx silo-mcp-accounts add dropbox --label personal

sequenceDiagram actor User participant Client as MCP Client<br/>(Claude) participant Silo as Silo MCP participant Src as Source cloud<br/>(Dropbox) participant Dst as Destination cloud<br/>(Google Drive) User->>Client: "Copy report.pdf from Dropbox to my Google Drive" Client->>Silo: copy_file(from=dropbox, to=google_drive, confirm=false) Silo-->>Client: dry run — will copy /report.pdf → google_drive:report.pdf Client-->>User: About to copy Dropbox → Google Drive. Approve? User->>Client: yes Client->>Silo: copy_file(…, confirm=true) Note over Silo: stream through a temp file<br/>the server controls Silo->>Src: download /report.pdf Src-->>Silo: bytes → temp file on disk Silo->>Dst: upload from temp file Dst-->>Silo: new file id + metadata Note over Silo: delete temp file,<br/>log 'copy' to the audit trail Silo-->>Client: copied ✓ Client-->>User: Done — report.pdf is now in your Google Drive

[!TIP] Dropbox is the one most likely to bite you: amissing_scope401 with an otherwise-correct token almost always means the scopes were changedafter*the token was generated. Regenerate the token, don't just re-save it.

local_pathfor uploads and the destination filename for downloads are both LLM-supplied tool-call arguments, so both are confined to one configured root each, in both directions:

- SILO_MCP_UPLOAD_ROOT(default~/silo-mcp/uploads) — files outside this directory can't be uploaded. This matters a lot here: without it, a manipulated conversation could ask the server to upload an arbitrary local file (SSH keys,.env, browser credential stores) to a cloud account — persistent, shareable, no visible platform artifact warning anyone something left the machine.
- SILO_MCP_DOWNLOAD_ROOT(default~/silo-mcp/downloads) — downloads can't be written outside this directory via a crafted filename.

Uploads are capped at 5 GiB (MAX_UPLOAD_BYTES) and downloads at 5 GiB (SILO_MCP_MAX_DOWNLOAD_BYTES, overridable). Downloads are streamed to disk and aborted mid-flight if they run over the cap, so an unexpectedly huge file can't exhaust memory. Credentials are stored in the OS keyring, never in the SQLite DB; the one-time OAuth authorization flow uses PKCE and a randomstatevalue (RFC 8252) so the loopback redirect can't be forged.

- Google Photos is upload-only.Google removed the Photos Library API's read-library scopes in March 2025 — an app can now only manage media items it created itself. Browsing or downloading a user's existing library needs the interactive "Picker API" (a web UI session), which a headless MCP tool call can't drive.list_files/download_file/search_filesall return a clear error rather than pretending to work.There is also no delete capability at all for Google Photos, in this project or Google's API— anything uploaded is permanent until removed manually via photos.google.com.
- Google Drive and Box address files by id, not path, for download/delete —upload'sremote_pathis used as a filename (Drive root / Box root folder only, no folder targeting in v1); to download/delete you need the id fromlist_files/search_filesfirst. OneDrive, Dropbox, and Yandex Disk use real paths throughout, no asymmetry.
- Object stores don't support search— only prefix listing vialist_files.search_filesreturns a clear "not supported" error. Yandex Disk has no dedicated search endpoint either and behaves the same way (path listing vialist_filesonly).
- Upload endpoints here are all single-shot (Dropbox ≤150MB, OneDrive ≤4MB); large-file chunked/resumable upload isn't implemented for any platform yet.

upload_file,delete_file, andcreate_share_linkall requireconfirm=true— they either mutate remote state or hand out a bearer-credential link.download_file/list_files/search_filesdon't gate, since they only write locally.

Dropbox, Google Drive, and Google Photos have been verified end-to-endover the actual MCP protocol— an MCP client spawns the server, does tool discovery, and calls the tools by name, exactly as Claude Desktop/ Code would — not just via direct Python calls.

Issues and PRs reporting real-account testing results for the remaining platforms are very welcome.