idrive-mcp-server

Ein MCP-Server (Model Context Protocol), der die Web-Backup-/Restore-Konsole von iDrive als Werkzeuge für einen MCP-kompatiblen KI-Assistenten (z. B. Claude Desktop oder Claude Code) bereitstellt. Er spricht mit der undokumentierten internen Web-API von iDrive – denselben Endpunkten, die auch die idrive.com-Konsole aufruft – unter Verwendung eines Session-Cookies, das aus einem angemeldeten Browser kopiert wird, da iDrive keine öffentliche API oder OAuth-Flow für diese Konsole anbietet. Siehe docs/api-map.md für die reverse-engineerte Endpunkt-Referenz, auf der dieser Server basiert.

Abrufen von IDRIVE_COOKIE

1. Melden Sie sich in Ihrem Browser bei idrive.com an.

2. Öffnen Sie DevTools -> Netzwerk-Tab.

3. Klicken Sie auf eine beliebige XHR-Anfrage an www.idrive.com.

4. Kopieren Sie den vollständigen Wert des Cookie-Headers dieser Anfrage.

5. Fügen Sie ihn in eine .env-Datei ein (kopieren Sie .env.example) als IDRIVE_COOKIE=<value>.

Dieses Cookie enthält ein Session-Token (SES_TOKEN, ein JWT), das nach etwa 24 Stunden abläuft – wenn das passiert, schlagen Tool-Aufrufe mit einer klaren Fehlermeldung „Sitzung aktualisieren" fehl, und Sie müssen die obigen Schritte wiederholen.

Related MCP server: Google Drive MCP Server

Konfiguration in Claude Code / Claude Desktop

Fügen Sie einen Eintrag zu Ihrer MCP-Konfiguration hinzu (.mcp.json für Claude Code oder claude_desktop_config.json für Claude Desktop):

{
  "mcpServers": {
    "idrive": {
      "command": "npx",
      "args": ["tsx", "src/index.ts"],
      "cwd": "/absolute/path/to/idrive-mcp-server",
      "env": {
        "IDRIVE_COOKIE": "<your cookie value>"
      }
    }
  }
}

Oder, nachdem Sie npm run build ausgeführt haben, richten Sie command/args auf die erstellte Ausgabe aus:

{
  "mcpServers": {
    "idrive": {
      "command": "node",
      "args": ["dist/index.js"],
      "cwd": "/absolute/path/to/idrive-mcp-server",
      "env": {
        "IDRIVE_COOKIE": "<your cookie value>"
      }
    }
  }
}

Verfügbare Tools

• list_devices — keine Eingabe. Listet jedes Gerät auf, das unter dem authentifizierten iDrive-Konto gesichert ist (Geräte-ID, Betriebssystem, Spitzname, IP-Adresse und Backup-Bucket-Speicherort) über den von EVS gehosteten Endpunkt evs/listDevices. Erfordert keine Konfiguration über IDRIVE_COOKIE hinaus.

• list_files — deviceId (erforderlich), path (Standard "/"), osType (Standard "win"). Durchsucht den gesicherten Dateibaum eines Geräts über den getRestoreData-Endpunkt von iDrive.

• browse_folder — deviceId (erforderlich), path (erforderlich, EVS-Format: "/C", "/C/Users/..."). Durchsucht den gesicherten Ordner eines Geräts über den umfangreicheren, von EVS gehosteten Endpunkt evs/browseFolder (fügt über list_files hinausgehende Felder für Papierkorb/Prüfsumme/Live-Image hinzu). Verwenden Sie zuerst list_files, um die verfügbaren Laufwerksbuchstaben/Wurzeln eines Geräts zu ermitteln, da evs/browseFolder noch nie mit einem bloßen Wurzelpfad beobachtet wurde.

• get_thumbnail — deviceId (erforderlich), path (erforderlich, gleiches EVS-Format wie browse_folder), timestamp (erforderlich — der lmd_web-Wert der Datei aus einem früheren list_files/browse_folder-Aufruf). Ruft ein Vorschaubild für eine gesicherte Datei über den von EVS gehosteten Endpunkt evs/getThumbnail ab, das als MCP-Bildinhalt zurückgegeben wird.

• download_file — deviceId (erforderlich), path (erforderlich, gleiches EVS-Format wie browse_folder). Lädt den tatsächlichen Inhalt einer gesicherten Datei über den von EVS gehosteten Endpunkt evs/downloadFile herunter, der als base64-kodierter MCP-Ressourceninhalt zurückgegeben wird. Der Content-Type von iDrive auf diesem Endpunkt ist nicht vertrauenswürdig, um den tatsächlichen Dateityp zu identifizieren — leiten Sie ihn stattdessen aus dem Namen/der Erweiterung der Datei ab.

• get_file_properties — deviceId (erforderlich), path (erforderlich, gleiches EVS-Format wie browse_folder). Ruft Metadaten zu Größe/letzter Änderung für eine einzelne gesicherte Datei oder einen Ordner über den von EVS gehosteten Endpunkt evs/getProperties ab.

• get_file_versions — deviceId (erforderlich), path (erforderlich, gleiches EVS-Format wie browse_folder). Listet frühere gesicherte Versionen einer Datei über den von EVS gehosteten Endpunkt evs/getVersions auf. Bisher ist nur die Antwortform „keine Versionshistorie" bestätigt — eine Datei ohne frühere Versionen wird als normales Ergebnis gemeldet (hasVersions: false), nicht als Tool-Fehler; die Form einer echten Versionsliste ist unbestätigt und wird als rohes JSON zurückgegeben.

• get_account_usage — keine Eingabe. Gibt das verwendete/gesamte Sync-Speicherkontingent des Kontos als rohe Zeichenfolgen zurück (z. B. "0.00 KB", "5000.00 GB"), extrahiert aus zwei Inline-<script>-Variablen auf der account.html-Seite von iDrive — es gibt keinen dedizierten JSON-Nutzungsendpunkt. Von Natur aus fragil (ein HTML-Scrape, keine stabile API) und spiegelt speziell die „Sync"-Kontingentbezeichnung der Seite wider; ob es auch die Gesamtnutzung über Gerätesicherungen darstellt, ist unbestätigt.

Verändernde Tools

Die folgenden Tools ändern echte gesicherte Daten auf dem Konto, anders als alle Tools oben (alle schreibgeschützt). Ihre Beschreibungen und MCP-annotations sagen dies explizit aus (readOnlyHint: false und destructiveHint: true für delete_file).

• create_folder — deviceId (erforderlich), parentPath (erforderlich, EVS-Format, muss ein vorhandener Ordner sein), folderName (erforderlich — nur der Name des neuen Ordners, kein Pfad). Erstellt einen neuen Ordner im Live-Backup eines Geräts über den von EVS gehosteten Endpunkt evs/createFolder. Live bestätigt: Der neue Ordner erscheint in nachfolgenden browse_folder/list_files-Auflistungen.

• delete_file — deviceId (erforderlich), paths (erforderlich, Array aus einem oder mehreren EVS-Format-Pfaden — gesendet als wiederholte p-Felder in einem einzigen Batch-Aufruf), permanent (optional, Standard false). Entfernt Datei(en)/Ordner aus dem Live-Backup eines Geräts über den von EVS gehosteten Endpunkt evs/v1/deleteFile. permanent: false (Standard) verschiebt die Pfade in den Papierkorb — live bestätigt und mit restore_from_trash wiederherstellbar. permanent: true sendet trash=no, was (aufgrund des Feldnamens/-musters) vermutlich eine dauerhafte, nicht wiederherstellbare Löschung bedeutet, aber dies wurde nie unabhängig live bestätigt — behandeln Sie es als unverifiziert, bevor Sie sich darauf verlassen.

• restore_from_trash — deviceId (erforderlich), paths (erforderlich, Array aus einem oder mehreren EVS-Format-Pfaden, gleiche wiederholte-p-Batchverarbeitung wie delete_file). Stellt zuvor in den Papierkorb verschobene Datei(en)/Ordner an ihrem ursprünglichen Speicherort wieder her über den von EVS gehosteten Endpunkt evs/putBackFromTrash. Live bestätigt. Es gibt keine bestätigte Möglichkeit, den aktuellen Inhalt des Papierkorbs aufzulisten, daher müssen paths bereits bekannt sein.

Alle von EVS gehosteten Tools (browse_folder, get_thumbnail, download_file, get_file_properties, get_file_versions, list_devices, create_folder, delete_file, restore_from_trash) bootstrappen und cachen transparent die EVSID-Sitzung, die der EVS-Satelliten-Host benötigt (siehe Abschnitt „EVSID: Wie die EVS-Sitzung tatsächlich aufgebaut wird" in docs/api-map.md) — es ist keine zusätzliche Konfiguration über IDRIVE_COOKIE hinaus erforderlich, aber sie benötigen den EVS_SERVER-Wert des Cookies (vorhanden auf Cookies, die von /idrive/home kopiert wurden, nicht unbedingt auf denen von der idriveent-Konsole), um zu wissen, gegen welchen EVS-Host gebootstrappt werden soll.

Testen

npm test führt die Unit-Tests bedingungslos aus, plus eine Reihe von Live-Integrationstests, die hinter Umgebungsvariablen geschaltet sind und sauber übersprungen werden, wenn sie nicht gesetzt sind:

• IDRIVE_COOKIE — erforderlich, damit überhaupt ein Integrationstest läuft.

• IDRIVE_TEST_DEVICE_ID — eine echte device_id (aus list_devices), die die meisten Integrationstests benötigen.

• IDRIVE_TEST_EVS_PATH — ein echter Pfad im EVS-Format (z. B. /C), unter dem die meisten Integrationstests browsen/lesen.

• IDRIVE_TEST_ALLOW_MUTATIONS=1 — eine separate, explizite Opt-in-Anforderung, zusätzlich zu den drei obigen Variablen, bevor der Integrationstest für create_folder/delete_file/restore_from_trash in src/tools/files.test.ts ausgeführt wird. Dieser Test mutiert ein echtes Konto: Er erstellt einen eindeutig benannten Wegwerf-Ordner unter IDRIVE_TEST_EVS_PATH (so dass wiederholte Läufe nie kollidieren), übt alle drei Tools darauf aus und räumt auf, indem er ihn vor Testende in den Papierkorb verschiebt — selbst wenn eine Assertion mittendrin fehlschlägt (try/finally). Ohne diese Variable, die exakt auf "1" gesetzt ist, wird dieser Test übersprungen, sodass ein Entwickler, der nur IDRIVE_COOKIE/IDRIVE_TEST_DEVICE_ID/IDRIVE_TEST_EVS_PATH für schreibgeschützte Tests eingerichtet hat, npm test ausführen kann, ohne dass echte Daten berührt werden.

Der Integrationstest für get_account_usage ist schreibgeschützt und benötigt nur IDRIVE_COOKIE, genau wie die anderen Kontotools.

Status

Das Laden der Konfiguration, die Erkennung des Sitzungsablaufs und der gemeinsame HTTP-Client (src/client/idriveClient.ts) sind vorhanden; MCP-Tools werden schrittweise unter src/tools/ hinzugefügt (siehe „Verfügbare Tools" oben).