Hosting im KI-Client (MCP)

Du kannst Dein Hosting direkt aus Deinem KI-Client bedienen — in normaler Sprache, ohne Dashboard und ohne fremde Konsole. Möglich macht das ein MCP-Server (Model Context Protocol), den STRYKE Hub bereitstellt.

Gedacht ist er für den Weg von lokal nach online: Dein Client holt sich zuerst den echten Zustand Deines Hostings, richtet Dir lokal dasselbe ein — und deployt am Ende aus demselben Fenster.

Was Du brauchst #

• ein STRYKE Hub Konto (der kostenlose Einstieg genügt)
• einen STRYKE Key aus Deinem Tresor
• einen KI-Client, der MCP über HTTP spricht: Claude Code, Cursor oder Claude Desktop

Der Zugang ist in jedem Tarif enthalten, auch im kostenlosen. Was Geld kostet, ist das Hosting selbst.

Schritt 1 — Schlüssel erzeugen #

Im Hub in den Tresor, Reiter Schlüssel, dann Neuer Key. Setze die Rechte:

• Hosting lesen — damit Dein Client den Zustand abfragen darf
• Hosting schreiben — damit er DNS setzen, anlegen und deployen darf

Der Schlüssel wird genau einmal angezeigt. Kopiere ihn sofort; danach siehst Du nur noch die ersten Zeichen zur Wiedererkennung.

Zwei Einstellungen, die sich lohnen: Du kannst den Schlüssel auf ein einzelnes Konto begrenzen und auf bestimmte IP-Bereiche. Beides wirkt sofort, und Du kannst ihn jederzeit widerrufen.

Schritt 2 — Client verbinden #

Claude Code:

claude mcp add --transport http stryke https://mcp.strykehub.de/mcp \
  --header "Authorization: Bearer DEIN_STRYKE_KEY"

Cursor — in ~/.cursor/mcp.json (global) oder .cursor/mcp.json im Projekt:

{
  "mcpServers": {
    "stryke": {
      "url": "https://mcp.strykehub.de/mcp",
      "headers": {
        "Authorization": "Bearer ${env:STRYKE_MCP_KEY}"
      }
    }
  }
}

Claude Desktop nimmt für eigene Verbindungen keinen fest eingetragenen Header entgegen. Dort führt der Weg über die Verbindungs-Verwaltung der Anwendung.

Tipp: Lege den Schlüssel als Umgebungs-Variable ab (STRYKE_MCP_KEY) statt ihn in eine Datei zu schreiben, die in einem Projekt liegt. Sonst landet er irgendwann in einem Repository.

Schritt 3 — Arbeiten #

Ab hier sprichst Du normal. Ein guter erster Satz:

„Liste meine Hosting-Konten auf und zeig mir zum ersten die Domains mit PHP-Fassung, die Datenbanken und welche Websites darauf laufen."

Und der Satz, für den das Ganze gebaut ist:

„Hol Dir den Zustand von meinem Hosting und richte mir das lokal genauso ein."

Dein Client liest dann Konto, Domain samt PHP-Fassung, Datenbanken, WordPress-Fassung, aktives Theme und Plugin-Liste — und baut daraus Deine lokale Umgebung. Wir liefern die Wahrheit über Dein Hosting; das Einrichten macht Dein Client auf Deinem Rechner.

Was er lesen kann #

Hosting-Konten und Konto-Übersicht · Serverinfos · Speicher, Traffic und Auslastung · Domains mit PHP-Fassung je Domain · Subdomains · DNS-Einträge · Datenbanken · FTP-Zugänge · den Stand einer laufenden Einrichtung · die Websites eines Kontos mit WordPress-Fassung und aktivem Theme · deren Plugins und Themes · Cloud-Dienste mit Zustand, Logs und Auslastung.

Was er verändern kann #

DNS-Einträge anlegen und ändern · Subdomains anlegen · Datenbanken anlegen · SSL einrichten · WordPress installieren · FTP-Zugänge anlegen · Cloud-Dienste deployen.

Jeder verändernde Aufruf sieht vorher nach, ob es das Gewünschte schon gibt. Ein zweiter Versuch mit denselben Angaben legt nichts Zweites an.

Was er bewusst nicht kann #

Nichts löschen. Keine Domain, kein Postfach, keine Datenbank, keinen Server. Es gibt kein Werkzeug dafür — das ist keine Einstellung, die sich aufdrehen lässt. Gelöscht wird ausschließlich im Dashboard, wo Du es bestätigst.

Nichts kaufen. Keine Domain registrieren, kein Kontingent zubuchen, keine Servergröße ändern. Ist ein Kontingent voll, sagt die Antwort, welches es ist und wo Du es selbst erweiterst — gebucht wird nichts.

Keine Zugangsdaten. Umgebungs-Variablen Deiner Cloud-Dienste werden nie ausgeliefert, damit sie gar nicht erst in den Kontext eines Sprachmodells geraten. Passwörter und API-Zugänge liegen verschlüsselt im Hub und werden nur serverseitig entschlüsselt.

Sicherheit #

Ein Schlüssel gehört zu Deinem Konto. Jeder Aufruf läuft durch dieselbe Rechte-Prüfung wie ein Klick im Dashboard — an fremde Konten kommt er nicht, auch nicht mit der richtigen Kennung. Zusätzlich gilt:

• Begrenzbar auf ein einzelnes Konto und auf IP-Bereiche
• Widerrufbar, jederzeit und sofort
• Protokolliert — jede Nutzung hinterlässt eine Spur
• Rotierbar — ein neuer Schlüssel übernimmt Rechte und Ablauf des alten

Verliert ein Schlüssel seine Vertraulichkeit — er lag in einem Repository, ein Rechner ist weg —, widerrufe ihn im Tresor und lege einen neuen an. Das dauert eine Minute und trifft nur diesen einen Schlüssel.

Wenn etwas nicht geht #

Dein Client zeigt keine Werkzeuge. Fast immer fehlen die Rechte am Schlüssel. Ohne „Hosting lesen" ist die Liste leer, und das sieht aus wie ein Verbindungsfehler.

„STRYKE Key required". Der Header fehlt oder der Schlüssel ist falsch kopiert. Er beginnt immer mit stk_key_.

Ein Aufruf wird abgewiesen, ohne dass ein Grund einleuchtet. Prüfe, ob der Schlüssel eine IP-Beschränkung trägt und Dein Client woanders läuft.

Die Plugin-Liste bleibt leer. Das braucht das STRYKE WP Plugin auf der Website. Eine Seite, die nur über Benutzername und Passwort angebunden ist, beantwortet das nicht — das ist kein Fehler.