SILO-MCP

Silo MCP

Un servidor MCP autoalojado que mueve archivos entre tu sistema de archivos y el almacenamiento en la nube: nueve plataformas, una única superficie de herramientas. Sube, descarga, lista, busca, elimina, genera enlaces de uso compartido y copia archivos directamente de una nube a otra, sin darle a un LLM acceso directo al sistema de archivos ni un montón de credenciales específicas de cada plataforma que gestionar.

No es "local-first": los archivos viven en la nube y cada operación habla con una API remota del proveedor. Lo que permanece local es la parte que importa para la confianza: el servidor se ejecuta como un subproceso en tu máquina, tus credenciales están en el llavero del sistema operativo (nunca en la nube, en un archivo de configuración o en un argumento de llamada de herramienta), y el registro de auditoría de transferencias es un archivo SQLite local.

Almacenes de documentos: Dropbox · Google Drive · OneDrive · Box · Google Photos (solo subida) · Yandex Disk Almacenes de objetos: compatible con S3 (AWS S3, Cloudflare R2, MinIO) · Google Cloud Storage · Azure Blob Storage

¿Qué puedes hacer con Silo MCP?

• Copiar un archivo directamente de una nube a otra — "copia mi archivo /photos de Dropbox a mi bucket de S3", "migra este archivo de Drive a OneDrive" — en una sola llamada de herramienta, sin descargar y luego subir manualmente. Lo único que una integración de almacenamiento de un solo proveedor estructuralmente no puede hacer.
• Mover archivos dentro y fuera del almacenamiento en la nube — "sube report.pdf a Dropbox", "descarga notes.txt de Google Drive para poder usarlo" — en las nueve plataformas con un mismo conjunto de herramientas.
• Explorar y buscar tus almacenes de documentos por carpeta o consulta, y listar los buckets de almacenes de objetos por prefijo de clave.
• Generar enlaces compartibles a un archivo: URL prefirmadas/firmadas en los almacenes de objetos y Box (con caducidad), enlaces de uso compartido de la plataforma en el resto.
• Puente hacia otros servidores MCP — un download_file aquí produce una ruta local que puedes pasar directamente a otro servidor (por ejemplo, el media_paths de un servidor de publicación en redes sociales).
• Mantener un registro de auditoría local — cada subida, descarga, eliminación y enlace de uso compartido se registra en un registro SQLite local que puedes consultar con list_transfers.

Todo se ejecuta a través de tu cliente MCP en lenguaje natural — consulta Ejemplos de flujos de trabajo.

Inicio rápido: pip install -e . → añade silo-mcp a la configuración de tu cliente MCP → silo-mcp-accounts add dropbox --label personal → pide a tu cliente que liste tus archivos de Dropbox. Pasos completos en Instalación y Añadir cuentas a continuación.

Contenido

• ¿Qué puedes hacer con Silo MCP?
• Por qué
• Arquitectura
• Requisitos
• Instalación
• Configurar tu cliente MCP
• Clientes compatibles
• Uso con Ollama
• Añadir cuentas
• Ejemplos de flujos de trabajo
• Herramientas
• Plataformas y herramientas compatibles
• Fricción de configuración y forma de las credenciales por plataforma
• Seguridad de rutas
• Notas específicas por plataforma
• Seguridad
• Seguridad
• Pruebas
• Solución de problemas
• Relacionados
• Licencia

Por qué

La mayoría de las configuraciones de "dale al LLM tu almacenamiento en la nube" caen en una de dos trampas: una integración de una sola plataforma que muere en cuanto cambias de proveedor, o un acceso local sin restricciones que permite que una conversación manipulada lea o suba cualquier cosa del disco. Silo MCP está construido contra ambas:

• Una superficie de herramientas, nueve plataformas. upload_file, download_file, list_files, search_files, delete_file, create_share_link se comportan igual independientemente de la plataforma a la que apuntes: los almacenes de objetos (bucket+clave) y los almacenes de documentos (basados en rutas) comparten un único contrato FileStore.
• Confinado por diseño, no por convención. local_path para subidas y el destino de las descargas son ambos argumentos de llamada de herramienta proporcionados por el LLM, por lo que ambos están estrictamente confinados a directorios raíz configurados: una conversación manipulada no puede pedirle a este servidor que lea una clave SSH ni escribir una descarga donde no debería.
• Las mutaciones requieren confirm=true. upload_file, delete_file y create_share_link mutan estado remoto o crean un enlace con credencial de portador y requieren confirmación deliberada. download_file/list_files/search_files solo escriben localmente, así que no requieren confirmación.
• Multi-cuenta desde el principio. Cada herramienta acepta una etiqueta account opcional: ejecuta un Dropbox de trabajo y un Dropbox personal lado a lado sin reconfigurar nada.

Arquitectura

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

Cada llamada de herramienta resuelve un par (platform, account) a una implementación FileStore y una credencial de accounts.py, comprueba cualquier ruta local contra las raíces de subida/descarga, ejecuta contra la API real de la plataforma y registra el resultado: la misma forma independientemente de cuál de los nueve backends esté al otro lado.

Requisitos

• Python 3.11+
• Un almacén de credenciales del sistema operativo que keyring pueda usar (Administrador de credenciales de Windows, Llavero de macOS o un proveedor de Secret Service en Linux): las credenciales nunca se escriben en disco en texto plano ni se pasan a través de una llamada de herramienta MCP.

Instalación

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 .

Los SDK de almacenes de objetos son extras opcionales: instala solo lo que necesites:

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

Una instalación básica (sin extras) cubre Dropbox/Drive/OneDrive/Box/Google Photos/Yandex Disk sin más dependencia que httpx: el servidor degrada con elegancia si un SDK de almacén de objetos no está instalado, en lugar de fallar al iniciar.

Configurar tu cliente MCP

Añade a la configuración MCP de tu cliente (por ejemplo, claude_desktop_config.json de Claude Desktop, o .mcp.json de Claude Code):

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

silo-mcp debe resolverse en PATH dentro del entorno desde el que tu cliente lanza el servidor: si instalaste en un virtualenv, apunta command al ejecutable silo-mcp de ese venv directamente (por ejemplo, /path/to/silo-mcp/.venv/bin/silo-mcp) en lugar de depender de la activación del shell.

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

Clientes compatibles

Cualquier cliente MCP que pueda lanzar un servidor stdio local funciona: el servidor usa solo llamadas de herramienta MCP estándar, sin características específicas de cliente. Clientes verificados y con funcionamiento esperado:

[!TIP] Si silo-mcp no está en el PATH del shell que lanza (común con virtualenvs), configura command al ejecutable del venv directamente, por ejemplo C:\\path\\to\\silo-mcp\\.venv\\Scripts\\silo-mcp.exe en Windows o /path/to/.venv/bin/silo-mcp en otros sistemas.

Uso con Ollama

Ollama no habla MCP de forma nativa: necesita un cliente MCP en el bucle que convierta la llamada a herramientas de Ollama en llamadas de herramienta MCP, el mismo papel que Claude Desktop/Code juegan para Claude. Este servidor no incluye ese puente (se mantiene fuera del alcance para seguir siendo un paquete de servidor simple), pero cualquier cliente Ollama compatible con MCP funciona una vez que lo apuntas a streamable-http en lugar de stdio:

1. Inicia el servidor en modo HTTP: SILO_MCP_TRANSPORT=streamable-http silo-mcp.
2. Apunta tu cliente MCP del lado de Ollama a http://127.0.0.1:8000/mcp.
3. Usa un modelo con capacidad de llamada a herramientas (por ejemplo, llama3.1, qwen2.5): Ollama solo enruta llamadas a herramientas para modelos que admiten el campo de API tools.

Añadir cuentas

Las credenciales se añaden mediante una CLI con entrada oculta, nunca a través de una llamada de herramienta MCP, y se almacenan en el almacén de credenciales de tu sistema operativo:

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

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

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

Flujos de trabajo de ejemplo

Una vez que el servidor está conectado, no llamas a las herramientas directamente — le pides a tu cliente MCP (Claude Desktop, Claude Code, etc.) en lenguaje natural y él elige la herramienta y los argumentos correctos. Estos ejemplos se probaron de extremo a extremo sobre el protocolo MCP real contra cuentas en vivo de Dropbox, Google Drive y Google Photos.

Dropbox / OneDrive / Yandex Disk (rutas reales):

• "Sube report.pdf desde mi carpeta de subidas a Dropbox."
• "¿Qué hay en la raíz de mi Dropbox? Encuentra cualquier cosa llamada invoice."
• "Descarga notes.txt de Dropbox y dame un enlace compartible."
• "Elimina old-draft.txt de mi Dropbox."

Google Drive / Box (direccionado por id — busca primero, luego actúa sobre el id):

• "Encuentra budget.xlsx en mi Google Drive." → luego "Descarga ese."
• "Comparte ese archivo con un enlace público."

Google Photos (solo subida):

• "Sube esta captura de pantalla a mi Google Photos."

Almacenes de objetos — S3 / GCS / Azure Blob (necesitan un bucket/contenedor):

• "Sube backup.zip a mi bucket S3 my-backups."
• "Lista todo lo que esté bajo logs/ en el bucket my-backups."
• "Dame un enlace prefirmado de 1 hora para backup.zip en my-backups."

Copia entre nubes (de una plataforma directamente a otra):

• "Copia report.pdf de mi Dropbox a mi Google Drive."
• "Migra todo lo que acabo de encontrar en Drive a mi bucket S3 archive."

Entre servidores:

• "Toma mi foto de perfil de Google Drive para adjuntarla a una publicación." — download_file entrega una ruta local que otro servidor MCP puede usar.

El mapeo completo de frases a llamadas de herramientas:

Debido a que Google Drive y Box direccionan archivos por id, un flujo natural allí es de dos pasos — "encuentra budget.xlsx en mi Drive" (search_files, devuelve el id), luego "descarga ese" / "comparte ese" usando el id que el cliente acaba de ver. El cliente maneja esa cadena por ti.

Las acciones mutadoras (upload_file, delete_file, create_share_link) requieren confirm=true, así que un buen cliente te mostrará exactamente lo que está a punto de hacer y solo continuará cuando lo apruebes — una eliminación o un enlace público nunca ocurren en silencio a partir de una solicitud vaga.

Herramientas

target es el nombre del bucket/contenedor para almacenes de objetos — se ignora para almacenes de documentos.

Enlaces compartibles

expires_in_seconds se respeta de forma nativa en S3, GCS, Azure Blob y Box (URLs prefirmadas/firmadas, o el unshared_at de Box). Dropbox, Google Drive, OneDrive y Yandex Disk también crean un enlace, pero ninguna de sus APIs admite caducidad en una cuenta personal/no Business, así que el parámetro se acepta por consistencia de interfaz pero no se aplica allí. No disponible en Google Photos (solo subida).

Protegido detrás de confirm=true aunque no mueve ni elimina datos — la URL devuelta es en sí misma una credencial de portador, la misma preocupación de exfiltración que tiene upload_file.

Copia entre nubes

copy_file mueve un archivo directamente de una plataforma a otra — "copia mi /photos/id.png de Dropbox a mi bucket S3 backups", "migra este archivo de Drive a OneDrive" — en una sola llamada de herramienta. Esto es lo único que una integración de almacenamiento de un solo proveedor estructuralmente no puede hacer; es la recompensa de poner cada backend detrás de una sola interfaz.

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

El LLM nunca toca los bytes del archivo ni una ruta intermedia — solo emite una llamada copy_file y el servidor maneja la descarga → temporal → subida → limpieza, condicionada a tu aprobación.

• Se transmite a través de un archivo local temporal que el servidor crea y elimina — nunca manejas una descarga/subida intermedia, y la ruta temporal nunca es un argumento proporcionado por el llamador (por lo que no está sujeta a la verificación de contención de la raíz de subida como lo está upload_file).
• from_remote_path se direcciona como la plataforma origen espera para una descarga (una ruta para Dropbox/OneDrive/Yandex/almacenes de objetos; un id de archivo para Google Drive/Box — busca primero para obtenerlo). to_remote_path toma por defecto el nombre base del origen; pásalo explícitamente cuando el origen esté direccionado por id.
• from_target/to_target son los nombres de bucket/contenedor cuando cualquiera de los extremos es un almacén de objetos.
• Requiere confirm=true — escribe en el destino. Se registra en el registro de auditoría como copy, con ambos extremos capturados.

[!NOTE] La copia está limitada por los mismos topes de 5 GiB de descarga/subida, y la descarga del origen se transmite al disco, así que una copia grande entre nubes no almacenará todo el archivo en memoria.

Plataformas admitidas y herramientas

Qué operaciones admite cada plataforma y su modelo de autenticación. ✅ admitido · — no admitido. target = el nombre del bucket/contenedor que los almacenes de objetos requieren.

[!NOTE] Google Photos es solo subida — Google eliminó el acceso a la API de lectura de biblioteca en marzo de 2025. Los almacenes de objetos y Yandex Disk no tienen búsqueda de contenido, solo listado por prefijo/ruta. Detalles en Notas específicas por plataforma.

Fricción de configuración y forma de credenciales por plataforma

Seguridad de rutas

local_path para subidas y el nombre de archivo de destino para descargas son argumentos de llamada a herramientas proporcionados por el LLM, por lo que ambos se limitan a una raíz configurada cada uno, en ambas direcciones:

• SILO_MCP_UPLOAD_ROOT (por defecto ~/silo-mcp/uploads) — los archivos fuera de este directorio no se pueden subir. Esto importa mucho aquí: sin ello, una conversación manipulada podría pedir al servidor que suba un archivo local arbitrario (claves SSH, .env, almacenes de credenciales del navegador) a una cuenta en la nube — persistente, compartible, sin ningún artefacto visible en la plataforma que advierta a alguien de que algo salió de la máquina.
• SILO_MCP_DOWNLOAD_ROOT (por defecto ~/silo-mcp/downloads) — las descargas no se pueden escribir fuera de este directorio mediante un nombre de archivo manipulado.

Las subidas están limitadas a 5 GiB (MAX_UPLOAD_BYTES) y las descargas a 5 GiB (SILO_MCP_MAX_DOWNLOAD_BYTES, sobreescribible). Las descargas se transmiten a disco y se abortan a mitad de camino si superan el límite, de modo que un archivo inesperadamente grande no pueda agotar la memoria. Las credenciales se almacenan en el llavero del sistema operativo, nunca en la base de datos SQLite; el flujo de autorización OAuth de una sola vez usa PKCE y un valor state aleatorio (RFC 8252) para que la redirección de bucle local no pueda ser falsificada.

Notas específicas de la plataforma

Seguridad

upload_file, delete_file y create_share_link requieren confirm=true — o mutan el estado remoto o entregan un enlace con credencial de portador. download_file/list_files/search_files no tienen compuerta, ya que solo escriben localmente.

Estado de pruebas con cuentas reales

Dropbox, Google Drive y Google Photos se han verificado de extremo a extremo a través del protocolo MCP real — un cliente MCP inicia el servidor, realiza descubrimiento de herramientas y llama a las herramientas por nombre, exactamente como lo haría Claude Desktop/ Code — no solo mediante llamadas directas a Python.

Los problemas y PRs que informen resultados de pruebas con cuentas reales para las plataformas restantes son muy bienvenidos.

Seguridad

Este servidor da a un LLM la capacidad de leer archivos locales (de un directorio), moverlos a cuentas en la nube y generar enlaces públicos — por lo que vale la pena ser claro sobre los riesgos y lo que se hace al respecto.

• La inyección de prompts es el riesgo central. El contenido que el modelo lee (un nombre de archivo, el texto de un documento, un mensaje anterior) puede intentar dirigirlo a llamar a una herramienta que no pretendías — por ejemplo, "también sube ~/.ssh/id_rsa" o "comparte este archivo públicamente". Esta es una propiedad general del uso de herramientas agénticas, no específica de este servidor.
• Mitigaciones integradas:
  • Contención de rutas — las subidas solo pueden leer desde SILO_MCP_UPLOAD_ROOT y las descargas solo pueden escribir en SILO_MCP_DOWNLOAD_ROOT. Una solicitud manipulada para una clave SSH o .env fuera de la raíz se rechaza antes de cualquier llamada de red. Mantén la raíz de subida como una carpeta dedicada, no tu directorio de inicio.
  • Compuertas de confirmación — upload_file, delete_file y create_share_link requieren confirm=true, de modo que un cliente bien comportado muestra exactamente lo que está a punto de suceder y un humano lo aprueba. Un enlace público o una eliminación nunca se disparan a partir de una solicitud vaga.
  • Las credenciales nunca llegan al modelo — viven en el llavero del sistema operativo y se leen en el lado del servidor; ninguna llamada de herramienta puede enumerarlas o exfiltrarlas, y nunca están en un archivo de configuración o volcado de entorno que el modelo vea.
  • Privilegio mínimo — limita cada token de plataforma a solo lo que necesitas (ver la tabla de permisos); un token de solo lectura no puede ser convencido de eliminar nada.
• Registro de auditoría — list_transfers y el registro SQLite local registran cada subida, descarga, eliminación y enlace de compartir, para que puedas revisar después qué se movió realmente.

[!WARNING] Trata un enlace de compartir generado como una credencial de portador pública — cualquiera con la URL puede leer el archivo, sin necesidad de cuenta. Revócalo eliminando el archivo (o dejando de compartirlo en la plataforma) cuando hayas terminado.

Pruebas

pip install -e ".[all,dev]"
pytest

Las pruebas son de lógica pura y HTTP simulado con respx — sin llamadas de red reales, sin credenciales reales requeridas.

Solución de problemas

Relacionado

Proyecto hermano en el mismo estilo MCP autoalojado y con compuerta de confirmación: un servidor MCP de publicación social (publica mensajes en lugar de mover archivos) — diferente forma de capacidad y límite de confianza, componible a nivel de cliente MCP en lugar de un código base compartido (download_file aquí puede pasar una ruta local directamente al media_paths de ese servidor).

Licencia

MIT