dynu-mcp

MCP-Server für Dynu — einen Anbieter für Dynamic DNS, Domain-Registrierung, E-Mail-Hosting und Cloud-Compute (VPS). Stellt die vollständige öffentliche Dynu REST-API v2 als MCP-Tools bereit.

Übersicht

• Zustandsloser HTTP-Dienst. Es werden niemals Anmeldeinformationen gespeichert — jede Anfrage liefert ihren eigenen API-Schlüssel über einen Header, der nur für die Lebensdauer dieser einzelnen Anfrage verwendet wird.

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

• Einstiegspunkte: POST /mcp (MCP-Protokoll) und GET /health (Gesundheitsprüfung).

• Standardport: 8080 (konfigurierbar über MCP_HTTP_PORT).

Related MCP server: dynadot-mcp

Umfang

30 Tools, reduziert von einem ursprünglichen Build mit 117 Tools, die die vollständige OpenAPI-3.0-Spezifikation von Dynu abdecken. Die Plattform, hinter der dieser MCP läuft, aggregiert die Tools jedes aktivierten Anbieter-MCPs in einen einzigen Gemini/Vertex-Modellaufruf, der bei insgesamt 512 Funktionsdeklarationen gedeckelt ist — bei über 50 registrierten Anbieter-MCPs muss jeder einzelne schlank bleiben. Beibehalten, über dieselben 6 Kategorien: dns (8 — der echte GET /dns-Endpunkt von MSPbots plus Kern-CRUD für Datensätze/Dienste), email (7 — Dienstliste/-details, Konto erstellen/lesen/aktualisieren/löschen), compute (4 — Instanzliste/-details/start/stopp), domain (2 — Liste/Details), monitor (7, vollständige Kategorie), ping (2, vollständige Kategorie). Vollständig entfernt: Verwaltung der Domain-Registrierung (Glue-Records, Nameserver, automatische Verlängerung, Sperren/Entsperren), E-Mail-Schwarz-/Weißlisten-/Alias-/Verteilerlisten-/DKIM-Verwaltung und Backup-/Snapshot-/VNC-/Neuinstallationsvorgänge von Compute — siehe Bekannte Lücken. MSPbots selbst ruft nur 1 Endpunkt auf (GET /dns), der beibehalten wird.

Authentifizierung

Dynu authentifiziert mit einem einzigen statischen API-Schlüssel (zu finden im Bereich API-Anmeldeinformationen des Dynu-Kontrollpanels). Die Integrationskonvention von MSPbots sendet diesen Schlüssel als Rohwert des API-Key-Headers, und dieser Server leitet ihn genau so weiter.

HEADER Erläuterung der Autorisierungsparameter

Fehlt der Header, wird 401 zurückgegeben:

{
  "error": "Missing credentials",
  "message": "This server requires the X-Dynu-Api-Key header",
  "required_headers": ["X-Dynu-Api-Key"],
  "optional_headers": []
}

Umgebungsvariablen

MCP-Endpunkt

• POST /mcp — MCP-Protokoll (streambarer HTTP-Transport)

• GET /health — Gesundheitsprüfung, gibt {"status": "ok"} zurück (reine lokale Lebendigkeitsprüfung, hängt nicht von der Dynu-API ab)

Werkzeugliste

Toolnamen werden aus der jeweiligen Zusammenfassung der Operation in der OpenAPI-Spezifikation des Anbieters abgeleitet (z. B. „Get a list of domains for DNS service" → dynu_get_list_domains_dns_service); die eine Namenskollision (sowohl GET /ping als auch POST /ping haben eine identische Zusammenfassung) wird durch ein _get/_post-Suffix eindeutig gemacht. body-Parameter für POST-Operationen werden als generisches dict akzeptiert — siehe den Models-Abschnitt der OpenAPI-Spezifikation des Anbieters (unten verlinkt) für die genauen Feldnamen/-typen jeder Ressource.

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-Dynu-Api-Key: <your-dynu-api-key>"   -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": "dynu_get_list_domains_dns_service",
      "arguments": {}
    }
  }'

Live-verifiziert (2026-07-29): dynu_get_list_domains_dns_service (derselbe Endpunkt, den MSPbots selbst aufruft, null Parameter) wurde Ende-zu-Ende über diesen laufenden Server mit einem echten API-Schlüssel aufgerufen und lieferte echte DNS-Domaindatensätze für das Konto zurück.

API-Referenz

• Übersicht: https://www.dynu.com/Support/API

• Offizielle OpenAPI-3.0-Spezifikation (Swagger): https://www.dynu.com/files/dynu.api/Dynu.API.OAS.zip

Bekannte Lücken

• Von 117 auf 30 Tools reduziert, durch ausdrückliche Benutzerentscheidung: Die Plattform, hinter der dieser MCP läuft, aggregiert die Tools jedes aktivierten Vendor-MCPs in einen einzigen Gemini/Vertex-Modellaufruf, der bei insgesamt 512 Funktionsdeklarationen gedeckelt ist – bei über 50 registrierten Vendor-MCPs muss jeder schlank bleiben. Behalten: MSPbots' echter GET /dns-Endpunkt, Kern-CRUD für DNS-Einträge/Dienste (8), Kern-CRUD für E-Mail-Dienste/Konten (7), grundlegende Compute-Instanz- Liste/Detail/Start/Stopp (4), Domänen-Liste/Detail (2) sowie Monitor/Ping in vollem Umfang (9). Vollständig entfernt: Domänen-Registrar-Verwaltung (Glue-Records, Nameserver, Auto-Verlängerung, Sperren/Entsperren/Stornieren), E-Mail- Blacklist/Whitelist/Alias/Verteilerlisten/DKIM-Verwaltung sowie Compute- Backup/Snapshot/VNC/Neuinstallation/Passwortänderung. Jede dieser Funktionen kann auf Anfrage wieder hinzugefügt werden, wenn ein realer Anwendungsfall sie benötigt.

• Schreiboperationen für Compute und Domänen bleiben risikoreicher, auch nach der Kürzung – dynu_start_instance/dynu_stop_suspend_instance wirken auf echte VPS-Instanzen. Behandeln Sie diese als destruktiv/irreversibel und bestätigen Sie sie vor dem Aufruf mit einem Menschen.

• body-Parameter sind untypisiert (dict) statt vollständig modelliert – der Abschnitt „Models" der OpenAPI-Spezifikation definiert das genaue Schema pro Ressource (z. B. DNS.dnsRecordA), aber die vollständige Abbildung aller als typisierte Python-Parameter war außerhalb des Rahmens. Aufrufer sollten das body-Dict gemäß der verlinkten Spezifikation gestalten.

• Nur dynu_get_list_domains_dns_service (MSPbots' eigener Endpunkt) wurde live mit echten Kontodaten verifiziert. Die übrigen 29 Tools sind strukturell korrekt (Schema validiert, MCP-Protokoll tools/list bestätigt, Tool-Anzahl nach der Kürzung erneut geprüft), aber nicht einzeln einem Smoke-Test unterzogen – mehrere sind Schreib-/destruktive Operationen, die echte DNS-Einträge, E-Mail-Konten oder VPS- Instanzen erstellen, ändern oder löschen würden, weshalb sie nicht gegen das Live- Testkonto ausgeführt wurden.