@prontosite/mcp 0.9.1 → 0.10.0

package/CHANGELOG.md

@@ -3,6 +3,26 @@
 Alle nennenswerten Änderungen am MCP-Server für ProntoSite. Der Server ist ein dünner Client um die
 ProntoSite Deploy-API; die eigentliche Logik lebt serverseitig.
 
+## 0.10.0 – 2026-10-03
+
+- **Neu: `account_create`** (schreibend, nur mit Betreuer-Token: admin/partner/agentur) – legt ein neues
+  Kundenkonto an (Dashboard-Weg „Kunde anlegen"). Mit `email` → eingeladenes Login-Konto (Invite-Mail),
+  ohne `email` → verwaltetes Konto (ohne Login). Partner/Agentur: Konto wird dem Betreuer zugeordnet,
+  Agentur-Kunden erhalten automatisch den Agentur-Plan (`agentur-kunde`/`billing_offline`). Antwort nennt die
+  neue Konto-ID (k-…) + den Hinweis, die erste Website per `site_deploy` mit `site="<k-id>:new"` zu importieren.
+  Schutz: Namens-/E-Mail-Dublette → Warnung mit vorhandener Konto-ID statt Doppelanlage (`override:true`
+  erzwingt die Namensdublette; eine vergebene E-Mail ist nicht erzwingbar), Rate-Limit 10 Konten/Stunde je Token.
+  Die Beschreibung lenkt den Assistenten dorthin, wenn es für einen Kunden noch KEIN Konto gibt (statt `site=new`).
+
+## 0.9.2 – 2026-10-01
+
+- **Pflicht-Marker in den Tool-Beschreibungen** (`site_deploy`, `site_legal_options`) + README: Rechtsseiten
+  bringen `data-ps="impressum"`/`"datenschutz"` + eine EIGENE `<h1>` mit (kein handgeschriebener Rechtstext) →
+  `site_legal_options` mit `showTitle:false` setzen (bei `?markers=auto` automatisch bei erkannter eigener H1);
+  Footer IMMER mit allen vier Markern (`link-impressum`, `link-datenschutz`, `cookie-einstellungen`,
+  `cookie-richtlinie`), sonst ungestylter Consent-Block; Mobile-Menü rendert als Drawer, Toggle braucht
+  `aria-controls`. Reine Beschreibungs-/Doku-Änderung (keine neue Funktion).
+
 ## 0.9.0 – 2026-09-27
 
 - **Neu: `site_widgets`** (lesend) – Katalog der verwalteten Widgets einer Website inkl. `aktiv`, `optionen`

package/README.md

@@ -82,6 +82,7 @@ sichern: `cp ~/.prontosite.json ~/.prontosite.json.bak`).
 | Tool | Wirkung |
 |------|---------|
 | `sites_list` | Alle erreichbaren Websites (Slug, Plan, letzte Änderung, Publish-Bedarf). **Lesend.** |
+| `account_create({ name, email?, plan?, note?, override? })` | **Nur mit Betreuer-Token.** Legt ein neues Kundenkonto an (Dashboard-Weg „Kunde anlegen"). Mit `email` → eingeladenes Login-Konto (Invite-Mail), ohne → verwaltetes Konto. Partner/Agentur: Konto wird dem Betreuer zugeordnet (Agentur-Kunden automatisch `agentur-kunde`). Antwort nennt die neue Konto-ID (k-…) → danach `site_deploy({ site: "<k-id>:new", zipPath })`. Namens-/E-Mail-Dublette → Warnung mit vorhandener k-ID (`override:true` erzwingt die Namensdublette). **Schreibend.** |
 | `site_status({ site? })` | Plan, Slug, Live-URL, Publish-Bedarf. **Lesend.** |
 | `site_export({ site?, which, outDir })` | ZIP (`published`\|`draft`\|`original`) lokal speichern. **Lesend.** |
 | `site_deploy({ site?, zipPath, publish?, resetOverlay?, legal?, company?, siteOverride? })` | ZIP importieren, optional live; optional Firmendaten im selben Aufruf setzen. Beim lokalen Bauen Bausteine im HTML per `data-ps` markieren (`formular:kontakt`, `impressum`/`datenschutz`, `link-impressum`/`link-datenschutz`) → [Marker-Syntax](https://prontosite.io/docs/marker-shortcodes). **Schreibend.** |
@@ -99,6 +100,21 @@ sichern: `cp ~/.prontosite.json ~/.prontosite.json.bak`).
 `site_deploy` und `site_publish` sind **schreibende** Aktionen (verändern die Live-Website). Die
 Tool-Beschreibungen weisen den Assistenten an, vorher rückzufragen. Jeder Aufruf wird serverseitig auditiert.
 
+### Pflicht-Marker beim lokalen Bauen
+
+Baust du das Template selbst, gehören drei Dinge dazu (volle Spec:
+[Marker-Syntax](https://prontosite.io/docs/marker-shortcodes)):
+
+- **Rechtsseiten:** `impressum/index.html` und `datenschutz/index.html` tragen IMMER
+  `<div data-ps="impressum">` bzw. `<div data-ps="datenschutz">` als Inhaltsbereich und eine **eigene `<h1>`**
+  (kein handgeschriebener Rechtstext). Danach `site_legal_options({ impressum:{ showTitle:false } })` setzen
+  (eigene H1 → keine doppelte Überschrift). Beim Erst-Import mit `?markers=auto`/der Rechts-Automatik setzt
+  ProntoSite `showTitle:false` automatisch, sobald die Rechtsseite eine eigene H1 hat.
+- **Footer:** IMMER alle vier Marker `link-impressum`, `link-datenschutz`, `cookie-einstellungen`,
+  `cookie-richtlinie` – sonst hängt das Consent-Widget einen ungestylten Block an den Seitenfuß (mehrsprachig
+  je Sprach-Footer dieselben Marker, Linktext lokalisiert).
+- **Mobile-Menü:** rendert als Drawer (von rechts); der Toggle braucht `aria-controls` auf das Menü.
+
 ## Arbeitsweise: ein Chat je Kunde
 
 Für saubere Trennung: pro Kundenwebsite **einen eigenen Claude-Chat**. So bezieht sich der ganze Verlauf auf
@@ -127,6 +143,11 @@ Admin/Partner-Bereich (Panel „Betreuer-Token"). Config dann einfach:
 zugeordnet ist – keine Config-Pflege). Website je Aufruf per Slug **oder stabiler Site-ID** angeben (kein
 `"active"` – es sind mehrere Konten). Erst-Import: `site_deploy({ site: "new", customer: "k-…" })`.
 
+**Neuen Kunden anlegen** (es gibt noch KEIN Konto): zuerst `account_create({ name, email? })` – das Konto wird
+dem Betreuer zugeordnet (Agentur-Kunden automatisch `agentur-kunde`). Die Antwort nennt die Konto-ID (k-…);
+danach die erste Website per `site_deploy({ site: "<k-id>:new", zipPath })` importieren. Also **nicht** `site=new`
+raten, solange die Konto-ID unbekannt ist – erst `account_create`.
+
 Sicherheit: der Zugriff wird bei JEDEM Aufruf serverseitig geprüft (`assertCanManage` – nur betreute Konten,
 Rollenentzug wirkt sofort); nur Deploy/Status/Export/Veröffentlichen, kein Konto-/Zahlungszugriff; optionaler
 Ablauf (Default 90 Tage) und optionale IP-Bindung; Widerruf sperrt alle betreuten Sites auf einmal.

package/api.mjs

@@ -159,6 +159,22 @@ export async function apiDeploy(cfg, { site, customer = null, slug: wishSlug = n
   return out;
 }
 
+/** POST /api/account – Kundenkonto per BETREUER-Token anlegen (Dashboard-Weg „Kunde anlegen"). Mit email →
+ *  eingeladenes Login-Konto (Invite-Mail), ohne email → verwaltetes Konto (ohne Login). Nutzt das Top-Level-
+ *  Betreuer-Token (nicht die sites-Map – ein Betreuer-Token gilt konto-übergreifend). */
+export async function apiAccountCreate(cfg, { name, email = null, plan = null, note = null, override = false } = {}, fetchImpl = fetch) {
+  if (!name || !String(name).trim()) throw new Error("name ist Pflicht (Anzeigename des Kunden).");
+  const token = needToken(cfg.token, "Betreuer-Token");
+  const body = { name: String(name).trim() };
+  if (email) body.email = String(email).trim();
+  if (plan) body.plan = String(plan).trim();
+  if (note) body.note = String(note).trim();
+  if (override === true) body.override = true;
+  const res = await fetchImpl(`${baseUrl(cfg)}/account`, {
+    method: "POST", headers: { ...authHeaders(token), "content-type": "application/json" }, body: JSON.stringify(body) });
+  return asJson(res);
+}
+
 /** POST /api/publish/<site> – erneut veröffentlichen (ohne ZIP). force=true = „trotzdem veröffentlichen"
  *  (auch ohne erkannte Änderung), analog zum Dashboard-Menüpunkt „Erneut veröffentlichen". */
 export async function apiPublish(cfg, { site, force = false } = {}, fetchImpl = fetch) {

package/index.mjs

@@ -11,13 +11,13 @@
 import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { z } from "zod";
-import { loadConfig, apiStatus, apiExport, apiDeploy, apiPublish, sitesList, apiCompanyGet, apiCompanySet, apiLegalOptions, apiDomainStatus, apiDomainConnect, apiEmbeds, apiEmbedConsent, apiWidgets, apiWidgetSet } from "./api.mjs";
+import { loadConfig, apiStatus, apiExport, apiDeploy, apiPublish, sitesList, apiAccountCreate, apiCompanyGet, apiCompanySet, apiLegalOptions, apiDomainStatus, apiDomainConnect, apiEmbeds, apiEmbedConsent, apiWidgets, apiWidgetSet } from "./api.mjs";
 
 const cfg = loadConfig();
 // Deutliche Startwarnung bei ambiger Konfiguration (Top-Level-Token NEBEN sites-Map). Nach stderr, damit
 // es im MCP-Log/Terminal auffällt; die endgültige Auflösung (Betreuer-Token-Vorrang vs. Map) klärt sites_list.
 for (const w of (cfg.warnings || [])) process.stderr.write("[prontosite-mcp] ⚠ " + w + "\n");
-const server = new McpServer({ name: "prontosite", version: "0.9.1" });
+const server = new McpServer({ name: "prontosite", version: "0.10.0" });
 const asText = obj => ({ content: [{ type: "text", text: JSON.stringify(obj, null, 2) }] });
 const asError = e => ({ isError: true, content: [{ type: "text", text: "Fehler: " + (e?.message || String(e)) }] });
 const SITE_DESC = "Website-Slug (z. B. 'mas-monti'). Ohne Angabe die Standard-Site der Config. Bei Betreuer-"
@@ -54,6 +54,29 @@ server.tool(
   async () => { try { return asText(await sitesList(cfg)); } catch (e) { return asError(e); } }
 );
 
+server.tool(
+  "account_create",
+  "SCHREIBEND (nur mit Betreuer-Token: admin/partner/agentur): Legt ein NEUES Kundenkonto an – der Dashboard-"
+    + "Weg „Kunde anlegen". Nutze dieses Tool, BEVOR du eine Website importierst, wenn es für den Kunden noch "
+    + "KEIN Konto gibt (z. B. sites_list zeigt den Kunden nicht, oder der Nutzer sagt „für Kunde X gibt es noch "
+    + "kein Konto"). Erst Konto anlegen, dann mit der zurückgegebenen Konto-ID (k-…) per site_deploy und "
+    + "site=\"<k-id>:new\" die erste Website importieren. Richte KEIN site=new/Erst-Import ein, solange die "
+    + "Konto-ID unbekannt ist – dann zuerst dieses Tool. Mit email wird ein Login-Konto angelegt und eine "
+    + "Einladungs-Mail verschickt; ohne email ein verwaltetes Konto (ohne Login, Betrieb über den Betreuer). "
+    + "Partner/Agentur: das Konto wird DIR zugeordnet; Agentur-Kunden erhalten automatisch den Agentur-Plan "
+    + "(Abrechnung über die Agentur). Schutz: bei gleichem Namen/gleicher E-Mail kommt eine Warnung mit der "
+    + "bereits vorhandenen Konto-ID statt einer Doppelanlage – mit override:true trotzdem anlegen. "
+    + "Bitte VOR dem Aufruf bestätigen lassen (es wird ggf. eine Mail an den Kunden gesendet).",
+  { name: z.string().describe("Pflicht: Anzeigename des Kunden (z. B. Firmenname)."),
+    email: z.string().optional().describe("Optional: E-Mail des Kunden. Gesetzt → eingeladenes Login-Konto (Invite-Mail); weggelassen → verwaltetes Konto ohne Login."),
+    plan: z.enum(["free", "agentur-kunde"]).optional().describe("Optional. Standard richtet sich nach dem Betreuer-Konto (Agentur → agentur-kunde, sonst free). Nur angeben, wenn du den Standard bestätigen willst."),
+    note: z.string().optional().describe("Optionale interne Notiz – erscheint im Konto-Verlauf des neuen Kontos."),
+    override: z.boolean().default(false).describe("true = eine Namensdublette-Warnung übergehen und trotzdem ein weiteres Konto anlegen. Eine bereits vergebene E-Mail lässt sich NICHT erzwingen.") },
+  async ({ name, email, plan, note, override }) => {
+    try { return asText(await apiAccountCreate(cfg, { name, email, plan, note, override })); } catch (e) { return asError(e); }
+  }
+);
+
 server.tool(
   "site_status",
   "Status einer ProntoSite-Website: Plan, Slug, Live-URL, letzte Änderungen und offener Veröffentlichungs"
@@ -85,6 +108,13 @@ server.tool(
     + "erscheinen sollen – data-ps=\"formular:kontakt\" (verwaltetes Kontaktformular), data-ps=\"impressum\" bzw. "
     + "data-ps=\"datenschutz\" (Rechtstext-Seite) und data-ps=\"link-impressum\" / data-ps=\"link-datenschutz\" "
     + "(Footer-Links auf die Rechtstexte). Beim Import legt ProntoSite die Bausteine automatisch an. "
+    + "PFLICHT-MARKER: (a) Rechtsseiten impressum/index.html + datenschutz/index.html tragen IMMER den "
+    + "data-ps-Marker als Inhaltsbereich UND eine EIGENE <h1>; schreib KEINEN Rechtstext von Hand hinein. Weil "
+    + "die Seite ihre eigene H1 hat, die Widget-Überschrift ausschalten – site_legal_options mit showTitle:false "
+    + "(bei ?markers=auto setzt ProntoSite das automatisch, sobald die Rechtsseite eine eigene H1 hat). "
+    + "(b) Footer IMMER mit allen vier Markern link-impressum, link-datenschutz, cookie-einstellungen, "
+    + "cookie-richtlinie (sonst hängt das Consent-Widget einen ungestylten Block an den Seitenfuß; mehrsprachig "
+    + "je Sprach-Footer dieselben Marker). (c) Mobile-Menü-Toggle braucht aria-controls (Menü rendert als Drawer). "
     + "Syntax-Referenz: https://prontosite.io/docs/marker-shortcodes",
   { site: z.string().optional().describe(SITE_DESC + " Erst-Import: 'new' (Einzel) bzw. '<label>:new' (Multi-Site). Betreuer-Token: '<Konto-ID>:new' (k-…) legt im betreuten Konto an – die Konto-ID im Label ersetzt den customer-Parameter. sites_list zeigt betreute Konten OHNE Website (needsFirstImport) samt ihrer k-ID."),
     slug: z.string().optional().describe("Erst-Import: gewünschte Web-Adresse (Subdomain-Label, z. B. 'wuerttemberg' → wuerttemberg.prontosite.io). Beim Erst-Import den Nutzer danach FRAGEN; wird sie weggelassen, leitet ProntoSite eine Adresse ab. Bei Updates ignoriert."),
@@ -135,7 +165,7 @@ server.tool(
 );
 
 const legalOptShape = z.object({
-  showTitle: z.boolean().optional().describe("Überschrift (H1) des Rechtstextes anzeigen (Default an)."),
+  showTitle: z.boolean().optional().describe("Widget-Überschrift des Rechtstextes anzeigen (Default an). Bringt die Rechtsseite ihre EIGENE <h1> mit (Pflicht-Marker-Konvention), hier showTitle:false setzen, sonst doppelte Überschrift."),
   showDate: z.boolean().optional().describe("Stand-Datum anzeigen (Default an; nur wo vorhanden, i. d. R. Datenschutz)."),
   draftNotice: z.boolean().optional().describe("Entwurfs-Hinweis in der VERÖFFENTLICHTEN Seite anzeigen (Default an)."),
 }).describe("Anzeige-Optionen einer Rechtstext-Rolle – Teil-Update, nur gesetzte Booleans wirken.");
@@ -146,7 +176,9 @@ server.tool(
     + "(Überschrift), showDate (Stand-Datum), draftNotice (Entwurfs-Hinweis in der Live-Ausgabe). OHNE impressum/"
     + "datenschutz nur LESEN. Teil-Update (nur gesetzte Felder). HINWEIS: draftNotice:false blendet den rechtlich "
     + "empfohlenen Entwurfs-Hinweis live aus (protokolliert) – bitte vorher bestätigen lassen. "
-    + "MARKER (beim lokalen Bauen): Rechtstext-Seiten und -Links im Template mit data-ps markieren – "
+    + "WICHTIG: Rechtsseiten sollen laut Konvention ihre EIGENE <h1> mitbringen (Marker data-ps=\"impressum\"/"
+    + "\"datenschutz\" als Inhaltsbereich) – dann hier showTitle:false setzen, damit keine doppelte Überschrift "
+    + "entsteht. MARKER (beim lokalen Bauen): Rechtstext-Seiten und -Links im Template mit data-ps markieren – "
     + "data-ps=\"impressum\" / data-ps=\"datenschutz\" (Seite) bzw. data-ps=\"link-impressum\" / "
     + "data-ps=\"link-datenschutz\" (Footer-Links). Syntax-Referenz: https://prontosite.io/docs/marker-shortcodes",
   { site: z.string().optional().describe(SITE_DESC),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@prontosite/mcp",
-  "version": "0.9.1",
+  "version": "0.10.0",
   "description": "MCP-Server für ProntoSite – Website-Status, Export, Deploy und Veröffentlichen direkt aus einem KI-Assistenten (Claude Desktop). Dünner Client um die ProntoSite Deploy-API.",
   "type": "module",
   "bin": {