Skip to main content
Glama

optimizely-test-data-mcp

Ein MCP-Server, der einen Inhaltsplan in ein importierbares Optimizely CMS 12 .episerverdata-Paket umwandelt.

Der Generator berührt niemals ein CMS. Er liest einen Content-Type-Export und schreibt eine Datei; ein Mensch exportiert das Schema und ein Mensch importiert das Ergebnis unter Admin → Import Data.

Verwendung

{
  "mcpServers": {
    "optimizely-testdata": {
      "command": "bunx",
      "args": ["optimizely-test-data-mcp@0.1.0"]
    }
  }
}

Pinnen Sie die Version. Eine nicht gepinnte Spezifikation wird bei jedem Sitzungsstart neu aufgelöst, anstatt aus dem Cache bedient zu werden – unter Windows gemessen ~11s pro Start gegenüber ~0.7s gepinnt.

npx funktioniert genauso, wenn Sie lieber nicht Bun verwenden möchten.

Related MCP server: PBIP Builder MCP Server

Werkzeuge

Tool

Zweck

load_schema

Lädt die Content-Typen der Website aus einem Admin → Export Data-Export (nur Content-Typen). Jedes andere Tool schlägt fehl, bis dies erfolgreich ist.

list_content_types

Findet die Typen, die die Website tatsächlich hat, gefiltert nach Art oder Name.

describe_content_type

Die Eigenschaften eines Typs, welche erforderlich sind, und ein bearbeitungsfertiges Plan-Skelett.

validate_plan

Überprüft einen Plan, ohne etwas zu schreiben. Fehler benennen die erwartete Form.

build_package

Schreibt die .episerverdata-Datei.

inspect_package

Fasst den Inhaltsbaum innerhalb eines vorhandenen Pakets zusammen.

Grenzen

Medien, Inline-Block-Eigenschaften, unveröffentlichte Inhalte, mehr als eine Sprache, Category und untypisiertes Json werden nicht generiert. Jeder Eigenschaftstyp ohne nachgewiesene Serialisierung wird mit einer Warnung leer gelassen, anstatt geraten zu werden – eine falsche Vermutung erzeugt Inhalte, die richtig aussehen und subtil falsch sind.

Funktionierend: Seiten, Blöcke, verschachtelte Seitenbäume, Text, HTML, ContentArea, Inhaltsreferenzen und {{date:±Nd}} / {{date:±Nh}} / {{date:±Nm}}-Tokens.

Veröffentlichung

  1. Erhöhen Sie die version in package.json.

  2. Committen, dann taggen und pushen:

git tag v0.2.0
git push origin v0.2.0

Der Workflow prüft den Tag gegen package.json, führt die Tests aus, baut dist/ und veröffentlicht über OIDC Trusted Publishing – kein Token zu speichern.

Veröffentlichen ist Aufgabe der CI. Es gibt keinen prepublishOnly-Hook, daher baut npm publish allein nicht: dist/ ist git-ignoriert, und das Veröffentlichen ohne es liefert ein Paket, dessen files: ["dist"] nichts entspricht. npm akzeptiert das und beendet mit 0, sodass nichts den Fehler meldet – die kaputte Version erreicht einfach die Nutzer. Falls Sie jemals von Hand veröffentlichen müssen, führen Sie zuerst bun run build aus.

Diese Handveröffentlichung ist genau einmal erforderlich: npm kann nur einem Paket vertrauen, das es bereits kennt. Veröffentlichen Sie 0.1.0 manuell (bun run build, dann npm publish nach npm login), und fügen Sie dann den vertrauenswürdigen Publisher unter Settings → Trusted Publisher des Pakets auf npmjs.com hinzu, der auf dieses Repository und publish.yml zeigt. Jede spätere Veröffentlichung erfolgt über einen Tag.

Verbraucher pinnen die von ihnen verwendete Version – siehe Konfiguration oben. Eine Erhöhung hier bewegt sie nicht, bis sie diesen Pin aktualisieren.

Related MCP Connectors

Related MCP Servers