covedataprotection-mcp

MCP-Server für Cove Data Protection (die Backup-/BDR-Plattform von N-able, ehemals N-able Backup / Backup Manager). Stellt die JSON-RPC-Management-Service-API des Backup Managers als MCP-Tools bereit.

Überblick

• Zustandsloser HTTP-Dienst. Es werden niemals Anmeldedaten gespeichert – jede Anfrage übermittelt ihre eigenen Anmeldedaten über Header, die nur für die Lebensdauer dieser einen Anfrage verwendet werden.

• Unterstützt gleichzeitige Anfragen; die Isolierung der Anmeldedaten pro Anfrage erfolgt über Python-contextvars, nicht über eine globale/geteilte Client-Instanz.

• Einstiegspunkte: POST /mcp (MCP-Protokoll) und GET /health (Health-Check).

• Standardport: 8080 (konfigurierbar über MCP_HTTP_PORT).

Related MCP server: spanning-mcp

Umfang

26 Tools, reduziert gegenüber einem ursprünglichen 247-Tool-Build mit vollem Schema (2026-08-04). MSPbots' eigene Integration für Cove Data Protection (live bestätigt über /web/int/sys/integration/api/list gegen die Produktionsplattform) ist mit genau 6 APIs konfiguriert, die auf die folgenden zugrunde liegenden JSON-RPC-Methoden abgebildet sind:

Die anderen 5 oben bestätigten echten Methoden wurden unverändert übernommen, plus Core-CRUD derselben Kategorie (Add/Get/Modify/Remove) für jeden der drei Ressourcentypen, die sie betreffen – accounts (9 Tools), partners (9 Tools), users (7 Tools) – plus GetServerInfo (1 Tool, Konnektivitäts-Selbsttest, verwendet für die ursprüngliche Live-Verifizierung unten). Jede andere Kategorie aus dem ursprünglichen 247-Tool-Build (notifications, storage_nodes, contacts, storage, view_delivery, labels, jobs, custom_columns, branding, products, eula, locations, countries, audit, email, regions, features, permissions, templates – 19 Kategorien, ~221 Tools) wurde vollständig entfernt, da sie von MSPbots nicht verwendet wird und nicht in den Zweck dieses Servers fällt.

Authentifizierung

Cove besitzt keinen statischen, langlebigen API-Schlüssel. Stattdessen beginnt jede Sitzung mit einem Login-Aufruf (partner + username + password), der ein kurzlebiges visa-Token zurückgibt (gültig ~15 Minuten), das jeden nachfolgenden Aufruf begleiten muss.

Dieser Server speichert kein visa über Anfragen hinweg zwischen – ein solches Zwischenspeichern würde bedeuten, Sitzungszustand zu persistieren, was der Anforderung „keine Speicherung von Anmeldedaten" widerspricht. Stattdessen führt api_client.CoveClient.call() bei jedem Tool-Aufruf ein neues Login durch und verwirft das resultierende visa anschließend – ein zusätzlicher HTTP-Roundtrip pro Aufruf wird gegen vollständige Zustandslosigkeit eingetauscht.

Header-Autorisierungsparameter

Fehlt einer der drei Header, wird 401 zurückgegeben:

{
  "error": "Missing credentials",
  "message": "This server requires the X-CoveDataProtection-Partner, X-CoveDataProtection-Username, and X-CoveDataProtection-Password headers",
  "required_headers": ["X-CoveDataProtection-Partner", "X-CoveDataProtection-Username", "X-CoveDataProtection-Password"],
  "optional_headers": []
}

Umgebungsvariablen

MCP-Endpunkt

• POST /mcp – MCP-Protokoll (streamabler HTTP-Transport)

• GET /health – Health-Check, gibt exakt {"status": "ok"} zurück (reine lokale Liveness-Prüfung; ruft die Cove-API nicht auf)

Tool-Liste

Toolnamen folgen dem Muster covedataprotection_<snake_case_method_name> – z. B. wird die JSON-RPC-Methode EnumerateAccountStatistics zu covedataprotection_enumerate_account_statistics. Parameternamen entsprechen den Parameternamen der jeweiligen JSON-RPC-Methode (camelCase → snake_case); komplexe Parameter mit Struct-/Enum-Typ werden als dict/str akzeptiert und unverändert an die Hersteller-API durchgereicht – was das in der Praxis bedeutet, siehe Bekannte Lücken.

Testbeispiel

# Health check
curl -s http://localhost:8080/health

# Call a tool via the MCP protocol (streamable HTTP) — requires an
# initialize handshake first per the MCP spec; abbreviated example below
# shows the tool-call request body only:
curl -s -X POST http://localhost:8080/mcp \
  -H "X-CoveDataProtection-Partner: <your-partner-name>" \
  -H "X-CoveDataProtection-Username: <your-username>" \
  -H "X-CoveDataProtection-Password: <your-password>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -H "mcp-session-id: <session-id-from-initialize>" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "covedataprotection_get_server_info",
      "arguments": {}
    }
  }'

Erwartet: 200 mit der Serverversion bei gültigen Anmeldedaten; bei ungültigen Anmeldedaten schlägt der Login-Aufruf selbst fehl und jedes Tool gibt eine strukturierte JSON-Fehlerhülle zurück, z. B.:

{"error":{"code":"unauthorized","message":"<vendor error message>","retryable":false}}

code ist einer der festen Werte not_configured / unauthorized / not_found / invalid_argument / rate_limited / upstream_error; retryable teilt dem Aufrufer mit, ob ein erneuter Versuch desselben Aufrufs erfolgreich sein könnte (nur bei rate_limited und upstream_error ist das der Fall). Tools werfen bei Geschäfts- oder Herstellerfehlern niemals Ausnahmen – diese Hülle wird als normale Tool-Ergebniszeichenfolge zurückgegeben.

Live-verifiziert (2026-07-29): covedataprotection_get_server_info (null Parameter) wurde Ende-zu-Ende über diesen laufenden Server mit einem echten Partner/Benutzername/Passwort aufgerufen und gab die tatsächliche Cove-Serverversion zurück – was bestätigt, dass die Login → visa → Methodenaufruf-Pipeline gegen die Live-API funktioniert, nicht nur strukturell.

API-Referenz

• Erste Schritte: https://developer.n-able.com/n-able-cove/docs/getting-started

• Autorisierung: https://developer.n-able.com/n-able-cove/docs/authorization

• Aufbau eines Aufrufs: https://developer.n-able.com/n-able-cove/docs/construct-a-json-rpc-api-call

• Vollständiges Methoden-/Struktur-/Enum-Schema (JSON): https://documentation.n-able.com/covedataprotection/Schema_23.3.json

Bekannte Lücken

• Am 2026-08-04 von 247 auf 26 Tools reduziert. Der ursprüngliche Build umfasste jede Methode im Management-Service-Schema. Gemäß einer späteren Scope-Entscheidung wurde dies auf das reduziert, was MSPbots' eigene Produktionsintegrationskonfiguration tatsächlich aufruft (live verifiziert über /web/int/sys/integration/api/list gegen app.mspbots.ai, Integrations-ID 2026570354981494786) plus Kern-CRUD derselben Kategorie – siehe den Scope-Abschnitt oben für die genaue API→Methoden-Zuordnung und die vollständige Liste der entfernten Kategorien. Die entfernten ~221 Tools (notifications, storage_nodes, contacts, storage, view_delivery, labels, jobs, custom_columns, branding, products, eula, locations, countries, audit, email, regions, features, permissions, templates) sind in diesem Build überhaupt nicht enthalten; falls ein zukünftiger Bedarf eines davon erfordert, dokumentiert das ursprüngliche Schema (Schema_23.3.json, unten verlinkt) weiterhin seine exakte Methodensignatur und es kann auf dieselbe Weise wieder hinzugefügt werden, wie die behaltenen Tools generiert wurden.

• Dies deckt nur den Management Service ab. Coves Getting-Started-Leitfaden beschreibt einen zweiten, separaten Reporting Service ({host}/repserv_json, läuft pro Storage-Node), der Backup-/Restore-Sitzungsstatistiken bereitstellt. MSPbots' eigene Konfiguration ruft einen „Query Sessions"-Bericht gegen diesen Reporting Service auf – er ist nicht Teil des Management-Service-Schemas, aus dem dieser MCP generiert wird, und es wurde kein öffentliches Schema für den Reporting Service gefunden. Dies ist der eine von MSPbots konfigurierte Endpunkt, den dieser MCP nicht abdeckt; er kann hinzugefügt werden, falls die Methodenliste/das Schema des Reporting Service verfügbar wird.

• Komplexe Struktur-/Enum-Parameter sind untypisiert (dict/str) statt vollständig modelliert. Das Schema definiert 106 Strukturen und 78 Enums; jede einzelne als typisierten Python-Parameter vollständig zu reproduzieren, war außerhalb des Rahmens für einen mechanisch generierten Server. Aufrufer müssen diese dict-Argumente so gestalten, dass sie dem Schema des Anbieters entsprechen (siehe den Abschnitt „Structs" in Schema_23.3.json für exakte Feldnamen) – die Beschreibung jedes solchen Parameters benennt die Struktur, auf die er abbildet, und verweist auf diese Schemadatei.

• Kein Visa-Caching – siehe den Abschnitt „Authentifizierung" oben. Jeder Tool-Aufruf führt seinen eigenen Login durch, was einfach und vollständig zustandslos ist, aber bedeutet, dass 2 HTTP-Anfragen an den Anbieter pro Tool-Aufruf statt 1 gesendet werden.

• Alle 26 Tools wurden direkt aus der eigenen Schemadatei des Anbieters codegeneriert, nicht von Hand geschrieben – Parameternamen/-typen sind nur so genau wie dieses Schema. covedataprotection_get_server_info war das eine Tool, das Ende-zu-Ende live verifiziert wurde; der Rest ist strukturell korrekt (Schema validiert, MCP-Protokoll-Tools/list bestätigt), aber nicht einzeln gegen echte Daten rauchgetestet.

Hinweise zur Einhaltung der MCP-SOP des Anbieters

• Die Tool-Anzahl (26) überschreitet die „sollte ≤20 sein"-Richtlinie der SOP. Bereits von 247 auf 26 reduziert (siehe oben); die verbleibenden 26 bilden 1:1 auf unterschiedliche JSON-RPC-Methoden über 3 Ressourcendomänen (Konten/Partner/Benutzer) ab, die nicht zusammengeführt werden können, ohne erforderliche Parameterunterscheidungen zu verlieren (z. B. get_*_info nach Name+Passwort vs. get_*_info_by_id nach numerischer ID sind unterschiedliche Lookup-Schlüssel, nicht dasselbe Tool mit einem optionalen Parameter).

• Auf keinem Tool existiert ein limit-/page_size-Skalarparameter. Keine der 26 Methoden stellt einen erstklassigen numerischen Seitengrößenparameter bereit – das eine Paginierungsförmige Feld (range auf EnumerateChildPartners) ist eine undurchsichtige Anbieterstruktur, die unverändert durchgereicht wird, und children_limit auf GetPartnerTree wird ebenfalls uninterpretiert direkt an den Anbieter durchgereicht. Es gibt nichts, das dieser Server gegen die Standard-50-/Hart-Obergrenze-200-Richtlinie der SOP klemmen könnte; falls sich herausstellt, dass die range-/Limit-Strukturen des Anbieterschemas ein eigenes dokumentiertes Maximum pro Seite haben, sollte das hier durchgesetzt werden, statt der generischen Fallback-Obergrenze der SOP.

• Kein Credential-Env-Var-Fallback. config.Settings hat kein Partner-/Benutzername-/Passwort-Feld; get_client_from_context gibt None zurück (→ not_configured-Envelope), wann immer die contextvar pro Anfrage nicht gesetzt ist. Es gibt keinen Codepfad, der auf eine Umgebungsvariable zurückfällt.

• Tool-Anmerkungen: jedes Lesetool (get_*, enumerate_*) ist mit readOnlyHint=True, idempotentHint=True markiert; add_*-Tools sind readOnlyHint=False, idempotentHint=False (zweimaliges Erstellen ist keine No-op); modify_*-/set_*-/remove_*-Tools sind readOnlyHint=False, destructiveHint=True, idempotentHint=True.