SILO-MCP

Silo MCP

Um servidor MCP auto-hospedado que move arquivos entre seu sistema de arquivos e armazenamento em nuvem — nove plataformas, uma única superfície de ferramentas. Envie, baixe, liste, pesquise, exclua, gere links de compartilhamento e copie arquivos diretamente de uma nuvem para outra, sem dar a um LLM acesso bruto ao sistema de arquivos ou um saco de credenciais específicas de plataforma para gerenciar.

Não é "local-first" — os arquivos vivem na nuvem e cada operação fala com uma API de provedor remoto. O que permanece local é a parte que importa para a confiança: o servidor roda como um subprocesso na sua máquina, suas credenciais ficam no chaveiro do sistema operacional (nunca na nuvem, em um arquivo de configuração ou em um argumento de chamada de ferramenta), e o log de auditoria de transferências é um arquivo SQLite local.

Armazenamentos de documentos: Dropbox · Google Drive · OneDrive · Box · Google Photos (somente upload) · Yandex Disk Armazenamentos de objetos: compatível com S3 (AWS S3, Cloudflare R2, MinIO) · Google Cloud Storage · Azure Blob Storage

O que você pode fazer com o Silo MCP?

• Copiar um arquivo diretamente de uma nuvem para outra — "copie meu arquivo /photos do Dropbox para meu bucket S3", "migre este arquivo do Drive para o OneDrive" — em uma única chamada de ferramenta, sem download manual seguido de upload. A única coisa que uma integração de armazenamento de um único fornecedor estruturalmente não consegue fazer.
• Mover arquivos para dentro e para fora do armazenamento em nuvem — "envie report.pdf para o Dropbox", "baixe notes.txt do Google Drive para que eu possa usá-lo" — em todas as nove plataformas com um único conjunto de ferramentas.
• Navegar e pesquisar seus armazenamentos de documentos por pasta ou consulta, e listar buckets de armazenamento de objetos por prefixo de chave.
• Gerar links compartilháveis para um arquivo — URLs pré-assinadas/assinadas nos armazenamentos de objetos e no Box (com expiração), links de compartilhamento da plataforma nos demais.
• Fazer ponte com outros servidores MCP — um download_file aqui gera um caminho local que você pode entregar diretamente a outro servidor (por exemplo, o media_paths de um servidor de postagem social).
• Manter uma trilha de auditoria local — cada upload, download, exclusão e link de compartilhamento é registrado em um log SQLite local que você pode consultar com list_transfers.

Tudo isso passa pelo seu cliente MCP em linguagem natural — veja Exemplos de fluxos de trabalho.

Início rápido: pip install -e . → adicione silo-mcp à configuração do seu cliente MCP → silo-mcp-accounts add dropbox --label personal → peça ao seu cliente para listar seus arquivos do Dropbox. Passos completos em Instalação e Adicionar contas abaixo.

Conteúdo

• O que você pode fazer com o Silo MCP?
• Por quê
• Arquitetura
• Requisitos
• Instalação
• Configure seu cliente MCP
• Clientes suportados
• Uso com Ollama
• Adicionar contas
• Exemplos de fluxos de trabalho
• Ferramentas
• Plataformas e ferramentas suportadas
• Atrito de configuração e formato de credenciais por plataforma
• Segurança de caminhos
• Notas específicas por plataforma
• Segurança
• Proteção
• Testes
• Solução de problemas
• Relacionados
• Licença

Por quê

A maioria das configurações de "dê ao LLM seu armazenamento em nuvem" cai em uma de duas armadilhas: uma integração de plataforma única que morre no momento em que você troca de provedor, ou acesso irrestrito a arquivos locais que permite que uma conversa manipulada leia ou envie qualquer coisa no disco. O Silo MCP é construído contra ambas:

• Uma superfície de ferramentas, nove plataformas. upload_file, download_file, list_files, search_files, delete_file, create_share_link se comportam da mesma forma independentemente da plataforma para a qual você os aponta — armazenamentos de objetos (bucket+chave) e armazenamentos de documentos (baseados em caminho) compartilham um único contrato FileStore.
• Confinado por design, não por convenção. local_path para uploads e o destino para downloads são ambos argumentos de chamada de ferramenta fornecidos pelo LLM, então ambos são rigidamente confinados a diretórios raiz configurados — uma conversa manipulada não pode pedir a este servidor para ler uma chave SSH ou gravar um download em um lugar onde não deveria.
• Mutações exigem confirm=true. upload_file, delete_file e create_share_link todas alteram estado remoto ou criam um link com credencial de portador e exigem confirmação deliberada. download_file/list_files/search_files apenas gravam localmente, então não exigem confirmação.
• Multi-contas desde o início. Cada ferramenta aceita um rótulo opcional account — execute um Dropbox de trabalho e um Dropbox pessoal lado a lado sem reconfigurar nada.

Arquitetura

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 chamada de ferramenta resolve um par (platform, account) para uma implementação FileStore e uma credencial de accounts.py, verifica qualquer caminho local contra as raízes de upload/download, executa contra a API real da plataforma e registra o resultado — o mesmo formato independentemente de qual dos nove backends está do outro lado.

Requisitos

• Python 3.11+
• Um armazenamento de credenciais do sistema operacional que keyring possa usar (Gerenciador de Credenciais do Windows, Chaveiro do macOS ou um provedor de Secret Service no Linux) — credenciais nunca são gravadas em disco em texto puro ou passadas por uma chamada de ferramenta MCP.

Instalação

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 .

Os SDKs de armazenamento de objetos são extras opcionais — instale apenas o que precisar:

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

Uma instalação principal (sem extras) cobre Dropbox/Drive/OneDrive/Box/Google Photos/Yandex Disk sem dependência além de httpx — o servidor degrada graciosamente se um SDK de armazenamento de objetos não estiver instalado, em vez de falhar ao iniciar.

Configure seu cliente MCP

Adicione à configuração MCP do seu cliente (por exemplo, o claude_desktop_config.json do Claude Desktop, ou o .mcp.json do Claude Code):

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

silo-mcp deve ser resolvível em PATH dentro do ambiente a partir do qual seu cliente inicia o servidor — se você instalou em um virtualenv, aponte command para o executável silo-mcp desse venv diretamente (por exemplo, /path/to/silo-mcp/.venv/bin/silo-mcp) em vez de depender da ativação do shell.

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

Clientes suportados

Qualquer cliente MCP que possa iniciar um servidor stdio local funciona — o servidor usa apenas chamadas de ferramenta MCP padrão, sem recursos específicos de cliente. Verificados e esperados para funcionar:

[!TIP] Se silo-mcp não estiver no PATH do shell de inicialização (comum com virtualenvs), defina command para o executável do venv diretamente, por exemplo, C:\\path\\to\\silo-mcp\\.venv\\Scripts\\silo-mcp.exe no Windows ou /path/to/.venv/bin/silo-mcp em outros sistemas.

Uso com Ollama

Ollama não fala MCP nativamente — ele precisa de um cliente MCP no meio que transforme a chamada de ferramentas do Ollama em chamadas de ferramenta MCP, o mesmo papel que Claude Desktop/Code desempenham para Claude. Este servidor não inclui essa ponte (mantida fora do escopo para permanecer um pacote de servidor simples), mas qualquer cliente Ollama com suporte a MCP funciona quando você o aponta para streamable-http em vez de stdio:

1. Inicie o servidor no modo HTTP: SILO_MCP_TRANSPORT=streamable-http silo-mcp.
2. Aponte seu cliente MCP do lado do Ollama para http://127.0.0.1:8000/mcp.
3. Use um modelo com capacidade de chamada de ferramentas (por exemplo, llama3.1, qwen2.5) — o Ollama só roteia chamadas de ferramentas para modelos que suportam o campo de API tools.

Adicionar contas

As credenciais são adicionadas via CLI com entrada oculta, nunca por uma chamada de ferramenta MCP, e armazenadas no armazenamento de credenciais do seu sistema operacional:

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

Exemplos de fluxos de trabalho

Uma vez que o servidor está conectado, você não chama as ferramentas diretamente — você pede ao seu cliente MCP (Claude Desktop, Claude Code, etc.) em linguagem natural e ele escolhe a ferramenta e os argumentos certos. Esses exemplos foram todos exercitados de ponta a ponta sobre o protocolo MCP real contra contas ativas do Dropbox, Google Drive e Google Photos.

Dropbox / OneDrive / Yandex Disk (caminhos reais):

• "Envie report.pdf da minha pasta de uploads para o Dropbox."
• "O que há na raiz do meu Dropbox? Encontre qualquer coisa chamada invoice."
• "Baixe notes.txt do Dropbox e me dê um link compartilhável para ele."
• "Exclua old-draft.txt do meu Dropbox."

Google Drive / Box (endereçado por id — pesquise primeiro, depois aja no id):

• "Encontre budget.xlsx no meu Google Drive." → depois "Baixe esse."
• "Compartilhe esse arquivo com um link público."

Google Photos (somente upload):

• "Envie esta captura de tela para o meu Google Photos."

Armazenamentos de objetos — S3 / GCS / Azure Blob (precisam de um bucket/contêiner):

• "Envie backup.zip para o meu bucket S3 my-backups."
• "Liste tudo sob logs/ no bucket my-backups."
• "Me dê um link pré-assinado de 1 hora para backup.zip em my-backups."

Cópia entre nuvens (de uma plataforma direto para outra):

• "Copie report.pdf do meu Dropbox para o meu Google Drive."
• "Migre tudo o que acabei de encontrar no Drive para o meu bucket S3 archive."

Entre servidores:

• "Pegue minha foto de perfil do Google Drive para eu anexá-la a um post." — download_file entrega um caminho local que outro servidor MCP pode usar.

O mapeamento completo de frases para chamadas de ferramenta:

Como o Google Drive e o Box endereçam arquivos por id, um fluxo natural lá é em duas etapas — "encontre budget.xlsx no meu Drive" (search_files, retorna o id), depois "baixe esse" / "compartilhe esse" usando o id que o cliente acabou de ver. O cliente cuida desse encadeamento para você.

Ações de mutação (upload_file, delete_file, create_share_link) exigem confirm=true, então um bom cliente mostrará exatamente o que está prestes a fazer e só prosseguirá após sua aprovação — uma exclusão ou um link público nunca acontece silenciosamente a partir de um pedido vago.

Ferramentas

target é o nome do bucket/contêiner para armazenamentos de objetos — ignorado para armazenamentos de documentos.

Links de compartilhamento

expires_in_seconds é honrado nativamente em S3, GCS, Azure Blob e Box (URLs pré-assinadas/assinadas, ou o unshared_at do Box). Dropbox, Google Drive, OneDrive e Yandex Disk também criam um link, mas nenhuma de suas APIs suporta expiração em conta pessoal/não comercial, então o parâmetro é aceito para consistência de interface, mas não é aplicado lá. Não disponível no Google Photos (somente upload).

Protegido por confirm=true mesmo que não mova ou exclua dados — a URL retornada é em si uma credencial de portador, a mesma preocupação de exfiltração que upload_file tem.

Cópia entre nuvens

copy_file move um arquivo diretamente de uma plataforma para outra — "copie meu /photos/id.png do Dropbox para meu bucket backups do S3", "migre este arquivo do Drive para o OneDrive" — em uma única chamada de ferramenta. Esta é a única coisa que uma integração de armazenamento de fornecedor único estruturalmente não pode fazer; é a recompensa de colocar todos os backends atrás de uma única interface.

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

O LLM nunca toca nos bytes do arquivo ou em um caminho intermediário — ele apenas emite uma chamada copy_file e o servidor cuida do download → temp → upload → limpeza, protegido pela sua aprovação.

• Ele transmite através de um arquivo local temporário que o servidor cria e exclui — você nunca lida com um download/upload intermediário, e o caminho temporário nunca é um argumento fornecido pelo chamador (portanto, não está sujeito à verificação de contenção da raiz de upload da mesma forma que upload_file está).
• from_remote_path é endereçado da forma que a plataforma de origem espera para um download (um caminho para Dropbox/OneDrive/Yandex/armazenamentos de objetos; um id de arquivo para Google Drive/Box — pesquise primeiro para obtê-lo). to_remote_path assume o nome base da origem por padrão; passe-o explicitamente quando a origem for endereçada por id.
• from_target/to_target são os nomes de bucket/contêiner quando qualquer extremidade é um armazenamento de objetos.
• Exige confirm=true — ele grava no destino. Registrado no log de auditoria como um copy, com ambas as extremidades capturadas.

[!NOTE] A cópia é limitada pelos mesmos limites de 5 GiB de download/upload, e o download da origem é transmitido para o disco, então uma cópia grande entre nuvens não armazenará o arquivo inteiro em memória.

Plataformas e ferramentas suportadas

Quais operações cada plataforma suporta e seu modelo de autenticação. ✅ suportado · — não suportado. target = o nome do bucket/contêiner que os armazenamentos de objetos exigem.

[!NOTE] Google Photos é somente upload — o Google removeu o acesso à API de leitura da biblioteca em março de 2025. Armazenamentos de objetos e Yandex Disk não têm pesquisa de conteúdo, apenas listagem por prefixo/caminho. Detalhes em Notas específicas da plataforma.

Fricção de configuração e formato de credenciais por plataforma

Segurança de caminhos

local_path para uploads e o nome do arquivo de destino para downloads são ambos argumentos de chamada de ferramenta fornecidos pelo LLM, então ambos ficam confinados a uma raiz configurada cada, nas duas direções:

• SILO_MCP_UPLOAD_ROOT (padrão ~/silo-mcp/uploads) — arquivos fora deste diretório não podem ser enviados. Isso importa muito aqui: sem isso, uma conversa manipulada poderia pedir ao servidor para enviar um arquivo local arbitrário (chaves SSH, .env, repositórios de credenciais do navegador) para uma conta na nuvem — persistente, compartilhável, sem nenhum artefato visível na plataforma avisando que algo saiu da máquina.
• SILO_MCP_DOWNLOAD_ROOT (padrão ~/silo-mcp/downloads) — downloads não podem ser gravados fora deste diretório por meio de um nome de arquivo forjado.

Uploads têm limite de 5 GiB (MAX_UPLOAD_BYTES) e downloads de 5 GiB (SILO_MCP_MAX_DOWNLOAD_BYTES, substituível). Downloads são transmitidos em fluxo para o disco e abortados no meio do caminho se ultrapassarem o limite, então um arquivo inesperadamente enorme não pode esgotar a memória. As credenciais são armazenadas no chaveiro do sistema operacional, nunca no banco SQLite; o fluxo de autorização OAuth de uso único usa PKCE e um valor state aleatório (RFC 8252) para que o redirecionamento de loopback não possa ser forjado.

Observações específicas por plataforma

Segurança

upload_file, delete_file e create_share_link exigem confirm=true — eles alteram o estado remoto ou fornecem um link com credencial de portador. download_file/list_files/search_files não exigem confirmação, pois apenas gravam localmente.

Status de testes com conta real

Dropbox, Google Drive e Google Photos foram verificados de ponta a ponta pelo protocolo MCP real — um cliente MCP inicia o servidor, faz a descoberta de ferramentas e chama as ferramentas pelo nome, exatamente como o Claude Desktop/ Code faria — não apenas por chamadas diretas em Python.

Issues e PRs relatando resultados de testes com conta real para as plataformas restantes são muito bem-vindos.

Segurança

Este servidor dá a um LLM a capacidade de ler arquivos locais (de um diretório), movê-los para contas na nuvem e gerar links públicos — então vale a pena deixar claros os riscos e o que é feito sobre eles.

• A injeção de prompt é o risco central. O conteúdo que o modelo lê (um nome de arquivo, o texto de um documento, uma mensagem anterior) pode tentar direcioná-lo a chamar uma ferramenta que você não pretendia — por exemplo, "também envie ~/.ssh/id_rsa" ou "compartilhe este arquivo publicamente". Esta é uma propriedade geral do uso de ferramentas agênticas, não específica deste servidor.
• Mitigações incorporadas:
  • Contenção de caminho — uploads só podem ler de SILO_MCP_UPLOAD_ROOT e downloads só podem gravar em SILO_MCP_DOWNLOAD_ROOT. Uma solicitação forjada por uma chave SSH ou .env fora da raiz é rejeitada antes de qualquer chamada de rede. Mantenha a raiz de upload como uma pasta dedicada, não seu diretório pessoal.
  • Portões de confirmação — upload_file, delete_file e create_share_link exigem confirm=true, então um cliente bem-comportado mostra exatamente o que está prestes a acontecer e um humano aprova. Um link público ou uma exclusão nunca são disparados por uma solicitação vaga.
  • As credenciais nunca chegam ao modelo — elas ficam no chaveiro do sistema operacional e são lidas no lado do servidor; nenhuma chamada de ferramenta pode enumerá-las ou exfiltrá-las, e elas nunca estão em um arquivo de configuração ou despejo de ambiente que o modelo veja.
  • Privilégio mínimo — limite o escopo de cada token de plataforma apenas ao que você precisa (veja a tabela de permissões); um token somente leitura não pode ser convencido a excluir nada.
• Trilha de auditoria — list_transfers e o log local em SQLite registram cada upload, download, exclusão e link de compartilhamento, para que você possa revisar depois o que realmente foi movido.

[!WARNING] Trate um link de compartilhamento gerado como uma credencial de portador pública — qualquer pessoa com a URL pode ler o arquivo, sem precisar de conta. Revogue excluindo o arquivo (ou deixando de compartilhá-lo na plataforma) quando terminar.

Testes

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

Os testes são de lógica pura e HTTP simulado com respx — sem chamadas de rede reais, sem credenciais reais necessárias.

Solução de problemas

Relacionados

Projeto irmão no mesmo estilo MCP auto-hospedado com confirmação: um servidor MCP de postagem social (transmite posts em vez de mover arquivos) — formato de capacidade e limite de confiança diferentes, componível no nível do cliente MCP em vez de um código compartilhado (o download_file aqui pode entregar um caminho local diretamente ao media_paths daquele servidor).

Licença

MIT