Doku › Für Entwickler

KI-Assistent (MCP)

Verbinde ProntoSite mit Claude Desktop und arbeite direkt im Chat: Status abfragen, deine Website als Datei sichern, eine neue Version hochladen und veröffentlichen – ganz ohne Terminal. Verfügbar ab dem Starter-Plan.

Technisch ist der MCP-Server ein dünner Client auf die Deploy-API – dieselben Aktionen, nur per Zuruf statt per curl.

Schritt für Schritt #

  1. Claude Desktop installieren und anmelden.
  2. Token erzeugen – im Dashboard unter Konto → API-Zugang auf Token erzeugen klicken und den Schlüssel (beginnt mit psk_) kopieren. Er wird nur einmal angezeigt.
  3. Verbindungs-Snippet einfügen – im selben Panel steht unter „Mit KI-Assistent verbinden (MCP)" ein fertiges Textstück mit deiner Website. Kopiere es und füge es in Claude Desktop ein unter Einstellungen → Entwickler → Konfiguration bearbeiten. Ersetze DEIN_TOKEN durch deinen Schlüssel:
{
  "mcpServers": {
    "prontosite": {
      "command": "npx",
      "args": ["-y", "@prontosite/mcp"],
      "env": { "PRONTOSITE_TOKEN": "DEIN_TOKEN", "PRONTOSITE_SITE": "active" }
    }
  }
}

PRONTOSITE_SITE: "active" nimmt einfach deine aktive Website – der robusteste Wert. Das Panel trägt hier alternativ deine feste Website-Kennung ein; die bleibt gleich, selbst wenn sich deine Adresse ändert. 4. Claude Desktop neu starten – fertig. Danach kennt der Assistent deine Website. Probiere es aus:

  • „Wie ist der Status meiner Website?"
  • „Exportiere die veröffentlichte Website als ZIP nach ~/Downloads."
  • „Lade diese Datei hoch und veröffentliche sie." (der Assistent fragt vor dem Veröffentlichen nach)

Windows (Claude Desktop) #

Unter Windows sind ein paar Details anders als auf macOS:

  1. Konfigurationsdatei: %APPDATA%\Claude\claude_desktop_config.json. Am schnellsten per Win + R → %APPDATA%\Claude eingeben → Enter; die Datei dort öffnen (bzw. anlegen).
  2. npx.cmd statt npx: Auf Windows heißt der Starter npx.cmd:
{
  "mcpServers": {
    "prontosite": {
      "command": "npx.cmd",
      "args": ["-y", "@prontosite/mcp"],
      "env": { "PRONTOSITE_TOKEN": "DEIN_TOKEN", "PRONTOSITE_SITE": "active" }
    }
  }
}
  1. Doppelte Backslashes in Pfaden: In JSON muss jeder Backslash verdoppelt werden – z. B. "C:\\Program Files\\nodejs\\npx.cmd". Ein einfacher \ führt zu einem Parse-Fehler.
  2. Claude Desktop komplett beenden – über die Taskleiste: Das Fenster zu schließen reicht nicht; Claude läuft im Hintergrund weiter und liest die Config nicht neu. Rechtsklick auf das Claude-Symbol in der Taskleiste (unten rechts, ggf. unter „^") → Beenden, dann neu starten.

Troubleshooting: „spawn … failed" / „spawn npx.cmd ENOENT" #

Der Fehler heißt: Windows findet npx.cmd im PATH des Claude-Prozesses nicht.

  • Prüfe, dass Node.js installiert ist (node --version in der Eingabeaufforderung).
  • Trag den absoluten Pfad zu npx.cmd als command ein (mit doppelten Backslashes), z. B. "command": "C:\\Program Files\\nodejs\\npx.cmd". Den Pfad findest du mit where npx.cmd in der Eingabeaufforderung.
  • Danach Claude Desktop wie oben über die Taskleiste beenden und neu starten.

Ohne Installation: Remote-Endpunkt (Cursor, Claude Code) #

Statt das Paket lokal zu starten, kannst du dich direkt mit https://app.prontosite.io/mcp verbinden (MCP über Streamable HTTP). Dieselben Werkzeuge, dieselben Regeln (Konfliktschutz, Sperre, Rückgängig) – nur ohne npx. Anmeldung entweder per Login und Freigabe-Seite (OAuth 2.1 – so verbinden sich Claude im Browser, Claude Mobile, ChatGPT; Anleitung: Mit KI verbinden) oder wie unten mit deinem API-Token als Header.

Claude Code:

claude mcp add --transport http prontosite https://app.prontosite.io/mcp --header "Authorization: Bearer DEIN_TOKEN"

Cursor (mcp.json):

{
  "mcpServers": {
    "prontosite": {
      "url": "https://app.prontosite.io/mcp",
      "headers": { "Authorization": "Bearer DEIN_TOKEN" }
    }
  }
}

Unterschiede zum lokalen Paket – der Server kann keine Dateien auf deinem Rechner lesen:

  • site_export liefert einen Download-Link (15 Minuten gültig, nur einmal abrufbar), z. B. curl -o site.zip '<downloadUrl>'.
  • Deploy in zwei Schritten: deploy_upload_begin liefert einen Upload-Link (15 Minuten, einmalig, max. 100 MB, nur ZIP) → curl -T site.zip '<uploadUrl>' → deploy_commit mit der uploadId.
  • Kunden anlegen und Domain verbinden gibt es remote nur mit Betreuer-Token.
  • Tarif: Im Free-Tarif kannst du über den Remote-Endpunkt lesen und den Entwurf bearbeiten; Veröffentlichen und ZIP-Deploy gibt es ab dem Starter-Tarif oder mit einer API-Freigabe deines Betreuers (im Dashboard veröffentlichen geht immer).

Jede Änderung erscheint im Verlauf der Website mit dem Weg „KI-Assistent (Remote-MCP)" und dem Namen deines Programms.

Sicherheit #

🔒 Behandle den Schlüssel wie ein Passwort. Wer ihn hat, kann deine Website veröffentlichen. Verrate ihn niemandem und trage ihn nicht in den Chat ein. Bei Verdacht im Dashboard (Konto → API-Zugang) widerrufen und einen neuen erzeugen – das geht jederzeit. Die schreibenden Aktionen (Deploy, Veröffentlichen) sind so eingerichtet, dass der Assistent vor dem Ausführen rückfragt.

Mehrere Websites betreuen? #

Zwei Wege – je nachdem, wie viele Konten du betreust:

Einzelkonto-Token (aus Konto → API-Zugang eines Kunden): gilt für genau dieses eine Konto. „Zeig mir alle meine Websites" (sites_list) zeigt damit nur diese eine Website. Geht ein Schlüssel verloren, sind die anderen unberührt. Gut, wenn du einzelne Seiten getrennt hältst (am übersichtlichsten ein Chat je Kunde).

Betreuer-Token (für Agenturen/Admins, im Dashboard unter Betreuer-Token): ein Token für alle von dir betreuten Kunden. sites_list zeigt damit automatisch alle Konten – keine sites-Map in der Config nötig. Der Zugriff wird bei jedem Aufruf geprüft (nur deine Kunden), nur Deploy/Status/Export/ Veröffentlichen, kein Konto-/Zahlungszugriff. Details: Deploy-API.

Kurz: Für mehrere Konten den Betreuer-Token nutzen – nicht mehrere Einzelkonto-Tokens zusammenstückeln. Meldet sites_list nur ein Konto, obwohl du mehrere betreust, benutzt du einen Einzelkonto-Token statt des Betreuer-Tokens.

Standard: direkt am Server-Entwurf arbeiten (ab 0.12) #

Ab 0.12 sagt der MCP-Server dem Assistenten beim Verbinden selbst, wie er arbeiten soll: direkt am Entwurf auf dem Server. Export und Deploy sind die Ausnahme für größere Umbauten oder wenn du ausdrücklich lokal arbeiten willst; veröffentlicht wird nur nach deiner Bestätigung im Chat – außer Änderungen sofort live ist an (ab Starter Standard): Dann ist jede Änderung nach wenigen Sekunden live, site_status meldet autoPublish:true. Für reine Textänderungen („Ändere die Telefonnummer auf …") gibt es site_edit_text: sucht den Text auf allen Seiten – auch in Links (tel:/mailto:) und Attributen –, ersetzt ihn in einem Aufruf (Formatierung bleibt, ein Rückgängig-Schritt; mit scope:"all" sofort überall, mit region:"footer" nur im Fußbereich) und fragt ohne scope bei mehreren Fundstellen erst nach. Rechtstexte bleiben unberührt; steht der Wert in den Firmendaten, weist die Antwort auf site_company_set hin. Für HTML/CSS die Datei-Tools (Skriptdateien/JavaScript siehe Preise und Texte in Skripten):

  1. site_status – zeigt draftRev, den Vorschau-Link (previewUrl) und, wer zuletzt etwas geändert hat (recentEdits) bzw. gerade daran arbeitet (lock).
  2. site_files / site_file_get – Datei holen; der Block overlay nennt Dashboard-Änderungen, die über dem Quelltext liegen. Große Dateien kommen in Teilen (Standard 60 KB): truncated: true und nextOffset sagen, ab wo weitergelesen wird (offset in Bytes). outline: true liefert nur eine Gliederung (Überschriften, Abschnitte, IDs mit Zeile und offset), damit die KI gezielt den passenden Teil lädt. site_file_put ersetzt immer die ganze Datei – nie mit einem Teil aufrufen.
  3. site_file_put – mit baseRev = draftRev aus Schritt 1/2. Kommt conflict: true, hat jemand dieselbe Datei geändert: Claude holt sie neu und setzt die Änderung neu auf (nichts wird überschrieben).
  4. site_status zeigt publishNeeded → site_publish (nach Rückfrage).

Preise und Texte in Skripten (JS) #

Steht ein Preis oder Text in einer JavaScript-Datei (z. B. ein Preisrechner), ändert ihn die KI wie jeden anderen Text mit site_edit_text und scope:"all" (ab 0.15). In Skriptdateien ersetzt der Server dabei nur in Texten, Zahlen und Kommentaren, nie im Programmcode; die Fundstellen stehen in skripte. Voraussetzung ist, dass JavaScript für die Website freigegeben ist.

Für Code-Änderungen gibt es site_file_get/site_file_put. Jede Änderung an einer Skriptdatei wirkt sofort wie HTML und CSS (bei „Änderungen sofort live" nach wenigen Sekunden), es gibt keine Prüfung und keine Wartezeit. Ohne JavaScript-Freigabe der Website sind Skriptdateien gesperrt (403); dann muss der Betreuer JavaScript für die Website einmalig freigeben.

Kommt im Skript eine neue externe Adresse dazu, meldet die Antwort jsExtern mit den Adressen, zusammen mit dem Hinweis „Externe Einbindung erkannt, Datenschutzerklärung prüfen". Die Änderung ist trotzdem gespeichert. Der Hinweis erscheint auch im Dashboard-Chat und im Konto-Verlauf. Erkannt werden Adressen, die als Text im Skript stehen (auch "https://" + "beispiel.de"), aber keine, die das Skript erst zur Laufzeit zusammensetzt. Die Datenschutzerklärung bleibt deine Aufgabe.

Betreuer sehen alle JS-Änderungen in der Verwaltung (Konto → Website-Karte „JS-Verlauf") oder lesend per MCP-Werkzeug site_js_review (nur mit Betreuer-Token). Am einfachsten ist es, Preise gar nicht erst im Skript zu hinterlegen – siehe Website-Spezifikation (Rechner-Parameter als data--Attribute oder config.json).

Für größere Umbauten bleibt site_export (which='draft') → lokal → site_deploy der richtige Weg – der Export trägt seinen Stand mit, ein Deploy über einen inzwischen geänderten Entwurf endet mit einem Konflikt-Hinweis statt einem stillen Überschreiben. Ab 0.12 ist dieser Stand (baseRev) beim Update Pflicht: ohne Export-ZIP baseRev aus site_status mitgeben.

Übersetzen und Texte überarbeiten (ab 0.12.2): site_page_texts liefert alle Texte einer Seite – Absätze, Überschriften, Menü- und Button-Texte, Bild-Beschreibungen (alt/title), Seitentitel und Meta-Beschreibung – ohne HTML; site_page_texts_set schreibt die neuen Texte in einem Aufruf zurück (ein Rückgängig-Schritt; Gestaltung, Klassen und Linkziele bleiben). Für eine neue Sprachfassung legt site_page_copy (z. B. index.html → en/index.html) die Kopie mit angepassten Pfaden an. Rechtstext-Seiten (Impressum/Datenschutz) sind ausgenommen.

Bilder (ab 0.13): media_upload_begin gibt einen Upload-Link (15 Minuten, einmalig). Kann der Assistent Dateien lesen, lädt er die Originaldatei selbst hoch; sonst schickt er dir den Link – am Handy kannst du direkt fotografieren. Danach media_upload_commit (Prüfung + Optimierung auf dem Server) und site_image_set setzt das Bild ein. Lokales Paket (ab 0.13.3): media_upload_file {path} lädt eine Datei vom eigenen Rechner in einem Schritt hoch und liefert die mediaId. Erlaubt sind nur Dateien unterhalb deines Benutzerordners, ohne Symlinks und versteckte Ordner. Typ und Größe (max. 15 MB) werden vor dem Senden geprüft, abgelehnte Dateien verlassen den Rechner nicht. Das hilft z. B. in Claude Desktop (Cowork), wenn die Sandbox selbst keine Verbindung zu app.prontosite.io hat. Website beim Namen nennen (ab 0.13.6): Statt des Slugs darf site auch der Firmenname, die Domain oder der Titel der Website sein (z. B. „Firat-Deveci" oder „firat-deveci.de"). Ist das eindeutig, wird ausgeführt und die Antwort nennt den Slug; passt es auf mehrere Websites, kommt eine Auswahlliste und es wird nichts geändert. site_status zeigt, was die Verbindung darf (canEditDraft, canPublish …, mit Grund). Markup über alle Seiten (ab 0.13.8): site_edit_html ersetzt ein HTML-Fragment (z. B. im Footer) auf allen Seiten in einem Aufruf – ein Rückgängig-Schritt. Das ProntoSite-Badge entsteht beim Ausliefern und lässt sich darüber nicht ändern. Rechtstexte extern (ab 0.20.0): site_legal_options nimmt externalImpressum und externalDatenschutz (https-URL, null nimmt sie weg). Wirkung und Prüfung unter Rechtstexte extern, Stand in site_status.legalExternal.

Nicht in Suchmaschinen (ab 0.19.0): site_seo_set (noindex) gilt für eigene Domain und prontosite.io-Adresse gleich, Details unter Nicht in Suchmaschinen. site_status zeigt den Stand im Feld seo. Badge ausblenden oder Variante setzen (ab 0.18.0): site_badge_set (aktiv, variant) gilt für die ganze Website, auf allen Tarifen. site_status zeigt den Stand im Feld badge (aktiv, variant, eingebaut, seiten, sichtbar). Formulare (ab 0.13.7): site_forms_get zeigt Empfänger, Spam-Schutz und Danke-Seite je Formular, site_forms_set ändert sie (Empfänger für alle oder je Formular, Spam-Schutz streng/normal/basis, Danke-Seite nur als eigene Seite) – nie per HTML. Jeder Empfänger-Wechsel steht mit alter und neuer Adresse im Verlauf. Formular-Anfragen (ab 0.16): site_inbox_list (Kurzform; Filter status neu/gelesen/erledigt/spam/papierkorb, form, seit/bis, Volltext q, limit ≤ 50, offset; ohne status ohne Spam und Papierkorb), site_inbox_get (alle Felder, Absender, Anhänge mit 15-Minuten-Download-Link, Verlauf), site_inbox_set_status (neu/gelesen/erledigt, spam ↔ kein-spam, bis 100 IDs; „kein-spam" sendet die Empfänger-Benachrichtigung nach, falls sie beim Spam-Treffer unterblieb), site_inbox_delete (Papierkorb, 30 Tage) / site_inbox_restore, site_inbox_stats (je Status/Formular, 30/90 Tage, Spam-Quote). Anfragen enthalten Besucherdaten: bei OAuth eigene Rechte anfragen bzw. anfragen:schreiben (beim Verbinden nie vorausgewählt, bestehende Freigaben bekommen sie nicht automatisch); API-Tokens von Kunden und Betreuern haben sie. site_status meldet canInbox/canInboxWrite und – mit Recht – die Anzahl je Status (anfragen). Keine Antwort-Mails über MCP; endgültig löschen nur im Dashboard. REST: GET /api/inbox/<site> (Liste, ?id= eine Anfrage, ?stats=1), POST /api/inbox/<site> mit {action:"status"|"delete"|"restore", ids, status}. Mehr: Anfragen mit KI verwalten. Rückgängig (ab 0.13.4): site_undo nimmt die letzte(n) Änderung(en) zurück (derselbe Verlauf wie der Rückgängig-Knopf im Dashboard, auch Bildtausch und Datei-Änderungen), site_redo stellt sie wieder her. Die Antwort nennt je Schritt Art, Seite und wer geändert hat. Medien löschen: site_media_delete verschiebt in den Papierkorb (30 Tage, nichts wird endgültig gelöscht); wird das Bild noch verwendet (Entwurf oder live), kommt eine Warnung statt der Löschung. site_media_restore holt es zurück. Beim Bildtausch bleibt die Website responsiv: srcset aus den Server-Varianten, vorhandenes sizes und <picture>-Quellen bleiben. Erlaubt sind Bilder (JPG, PNG, WebP, SVG) und PDF – PDFs mit Skripten, automatischen Aktionen, Formular-Versand oder eingebetteten Dateien werden abgelehnt (wie im Dashboard); Office-Dokumente folgen mit dem Virenscanner. Design prüfen: site_preview_screenshot zeigt den Entwurf als Bild (Desktop 1280 px oder Smartphone 390 px).

Wenn mehrere an einer Website arbeiten: site_lock zeigt allen anderen „In Bearbeitung durch …" (2 Stunden, verlängert sich bei jeder Änderung), site_unlock gibt frei. Die Sperre informiert nur – sie hält niemanden auf. Mehr dazu: Mehrere Personen an einer Website.

Neuen Kunden anlegen (nur mit Betreuer-Token) #

Gibt es für einen Kunden noch kein Konto, legst du es mit account_create an – der gleiche Weg wie „Kunde anlegen" im Dashboard. Sag dem Assistenten z. B. „Für den Kunden Bäckerei Sonntag gibt es noch kein Konto, leg eins an". Felder:

  • name (Pflicht) – Anzeigename des Kunden (meist der Firmenname).
  • email (optional) – gesetzt: der Kunde bekommt eine Einladungs-Mail und meldet sich selbst an; weggelassen: ein verwaltetes Konto ohne Login (du pflegst es als Betreuer).
  • plan (optional) – Standard richtet sich nach deinem Konto: als Agentur wird der Kunde automatisch als agentur-kunde angelegt (Abrechnung über die Agentur), sonst free.
  • note (optional) – interne Notiz, erscheint im Verlauf des neuen Kontos.

Das Konto wird dir zugeordnet (Partner/Agentur). Die Antwort nennt die neue Konto-ID (k-…). Damit importierst du direkt die erste Website:

account_create({ name: "Bäckerei Sonntag", email: "info@baeckerei-sonntag.de" })
→ { customerId: "k-ab12cd34ef", … , siteArg: "k-ab12cd34ef:new" }

site_deploy({ site: "k-ab12cd34ef:new", zipPath: "…/baeckerei.zip" })

Also nicht site=new raten, solange die Konto-ID unbekannt ist – erst account_create, dann der Erst-Import mit site="<k-id>:new". Schutz gegen Doppelanlagen: bei gleichem Namen oder gleicher E-Mail kommt eine Warnung mit der bereits vorhandenen Konto-ID statt eines zweiten Kontos; eine Namensdublette lässt sich mit override: true bewusst erzwingen (eine bereits vergebene E-Mail nicht).

Zuletzt aktualisiert: