Datto BCDR MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HOST | No | HTTP only. Host to bind | 127.0.0.1 |
| PORT | No | HTTP only. Port to bind | 3000 |
| ALLOWED_HOSTS | No | HTTP only. Host header allowlist (DNS rebinding protection), e.g. mcp.example.com | |
| MCP_TRANSPORT | No | stdio or http | stdio |
| MCP_AUTH_TOKEN | No | HTTP only. Bearer token for /mcp and /api. Always set it when the server is reachable from the network | |
| DATTO_BCDR_BASE_URL | No | Datto BCDR API base URL | https://api.datto.com/v1/bcdr |
| DATTO_BCDR_PUBLIC_KEY | Yes | Public key (Basic Auth username) | |
| DATTO_BCDR_SECRET_KEY | Yes | Secret key (Basic Auth password) | |
| DATTO_BCDR_TIMEOUT_MS | No | Timeout per request | 30000 |
| DATTO_BCDR_CONCURRENCY | No | Parallel requests during fleet scans | 5 |
| DATTO_BCDR_CACHE_TTL_SECONDS | No | GET cache TTL, 0 disables it | 60 |
| DATTO_BCDR_RATE_LIMIT_PER_MINUTE | No | Datto allows roughly 120/min per key | 100 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list-devicesA | Listet alle BCDR-Geräte (SIRIS, ALTO, CLDSIRIS) mit Kunde, Modell, Online-Status, Agent-/Share-Anzahl und offenen Alerts. |
| get-deviceB | Details eines Geräts: Modell, Kunde, Online-Status, Speicherbelegung lokal/offsite, Region (CLDSIRIS), Garantie. |
| list-device-assetsA | Alle geschützten Agents und Shares eines Geräts mit letztem Snapshot, Offsite-Sync, Screenshot-Verification und letztem Backup-Status. |
| list-alertsA | Aktive (nicht geräumte) Alerts. Mit Seriennummer für ein Gerät, ohne Seriennummer flottenweit (nur Geräte mit Alerts). |
| list-active-restoresA | Laufende VM-Restores/Virtualisierungen. Ohne Seriennummer wird die ganze Flotte geprüft und nur Geräte mit aktiven Restores zurückgegeben. |
| get-backup-health-summaryA | Prüft alle Geräte und Agents gegen Schwellwerte und gibt NUR Problemfälle zurück. Kritisch: Gerät offline, Snapshot zu alt/fehlend, letzter Backup-Lauf fehlgeschlagen, lokaler Speicher >= 95 %, Datto-Servicevertrag abgelaufen. Warnung: Offsite-Sync zu alt, Screenshot-Verification fehlgeschlagen/zu alt, lokale Verifikation fehlgeschlagen, lokaler Speicher über Schwellwert, Servicevertrag endet bald, Agent pausiert, Volumes nicht im Backup. Archivierte Agents werden übersprungen. Standard: Snapshot 24 h, Offsite 48 h, Screenshot 7 d, Offline 1 h, Speicher 85 %, Servicevertrag 30 d. |
| find-assetA | Sucht einen geschützten Server/Agent oder Share über Hostname/FQDN auf allen Geräten und liefert Gerät, Kunde und Backup-Status. |
| get-screenshot-failuresB | Agents, deren Screenshot-Verification in den letzten X Tagen fehlgeschlagen ist (letzter Versuch oder Backups im Zeitraum). |
| get-client-overviewA | Rollup pro Kunde: Geräte (online/offline), geschützte Agents/Shares, Anzahl kritischer und Warn-Befunde, Ampelstatus. Gut für Monatsreports, QBRs und 'wie steht Kunde X da?'. Nutzt dieselben Schwellwerte wie get-backup-health-summary. |
| get-screenshotA | Lädt das letzte Screenshot-Verification-Bild eines Agents, damit du siehst, warum der Boot-Test fehlschlug (Bluescreen, Login-Fenster, Updates, Black Screen). Gibt das Bild plus Status zurück. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
Most tools have clearly distinct scopes, but get-backup-health-summary, get-client-overview, get-screenshot-failures, and list-device-assets overlap around backup health and screenshot verification. The descriptions clarify fleet-wide problems vs client rollup vs per-device asset status, so confusion is limited but not impossible.
All tool names use snake_case and consistently start with get, list, or find followed by a resource/action phrase. There are no mixed conventions such as camelCase or vague standalone verbs.
Ten tools is well-scoped for a BCDR monitoring server, covering devices, assets, alerts, restores, health summaries, screenshots, and client overviews. Each tool appears to earn its place without obvious redundancy.
The read-only monitoring surface is strong, with device, asset, alert, restore, health, and screenshot views. Minor gaps exist for operational follow-up, such as alert acknowledgement/resolution, restore start/cancel, alert detail, and a client-list tool.