WP-LIT-MCP/docs/guides/content-types.md

Inhalte, Felder und Status

Werkzeugnamen: lit-… sind direkt aufrufbare Tools; lit/… sind Abilities, die über mcp-adapter-execute-ability (Name in ability_name, Eingaben in parameters) aufgerufen werden.

Inhaltstypen erkennen

• lit-content-types ohne Parameter listet alle Inhaltstypen (Seiten, Beiträge, eigene Typen) mit Taxonomien, Anzahl und ob Divi dafür aktiv ist.
• lit-content-types mit post_type liefert zusätzlich alle Felder: Schlüssel, Typ, Pflicht, Auswahlwerte (choices), Beziehungsziel (related) und Schreibstatus:
  • writable – sicher beschreibbar (Pods-Feld oder registriertes Meta-Feld),
  • readonly – nicht beschreibbar,
  • unknown – vorhandener Meta-Schlüssel ohne bekannten Typ; Schreiben geht, der Wert wird unverändert gespeichert (Warnung in der Antwort).

Lesen und Suchen

• lit-content-query: Filter status, search, taxonomy ({taxonomy, terms: [IDs oder Slugs]}), field ({key, value, compare}), date_after/date_before (JJJJ-MM-TT), parent; Blättern mit next_cursor → cursor. field und taxonomy sind auf Feld- bzw. Taxonomienamen beschränkt, die lit-content-types für diesen Inhaltstyp auch anzeigt – ein unbekannter Name wird abgelehnt, keine leere Trefferliste. Geliefert werden nur Einträge, die der verbundene Nutzer selbst bearbeiten darf (fremde Entwürfe/private Inhalte ohne die passende Berechtigung erscheinen nicht).
• lit-content-get: alle Daten eines Eintrags inkl. Feldern, Begriffen, Beitragsbild und rev. Bei Divi-Seiten fehlt content; hints verweist auf lit-divi-outline.

Anlegen und Ändern

• lit-content-create legt immer einen Entwurf an. Felder werden gegen das Schema geprüft; ein Fehler bricht den ganzen Aufruf ab (fields.<schlüssel> im Fehler nennt die Ursache).
• lit-content-update ändert nur die übergebenen Werte, der Status bleibt. rev aus lit-content-get ist Pflicht – hat jemand parallel gespeichert (Inhalt, Titel, Auszug, Status oder irgendetwas anderes am Eintrag), kommt rev_mismatch: neu lesen, Änderung auf dem aktuellen Stand wiederholen.
• Begriffe: terms: {"category": [4, "Neuer Begriff"]} ersetzt die Zuordnung dieser Taxonomie (IDs oder Namen; unbekannte Namen werden angelegt, falls erlaubt).
• Felder leeren: Wert null. Pflichtfelder können nicht geleert werden.
• Beziehungsfelder erwarten IDs von Einträgen, die der Nutzer lesen darf; Datei-/Bildfelder Anhang-IDs aus der Mediathek.
• Einträge im Papierkorb werden nicht geändert (auch nicht veröffentlicht, geplant oder wiederhergestellt); zuerst in WordPress aus dem Papierkorb holen.
• Ist ein geplanter Eintrag über seinen Veröffentlichungszeitpunkt hinaus (verpasster Termin), würde jedes Speichern ihn sofort veröffentlichen – lit-content-update, lit/revision-restore und lit/post-replace-with-copy verweigern das dann. Mit dem Nutzer klären: jetzt veröffentlichen (lit-post-publish) oder neu planen (lit/post-schedule).

Status

• Veröffentlichen, Zurückziehen und Planen sind eigene Werkzeuge (lit-post-publish, lit/post-unpublish, lit/post-schedule mit date = „JJJJ-MM-TT HH:MM“ in der Zeitzone der Website). Nur auf ausdrücklichen Wunsch des Nutzers verwenden.
• lit/post-trash legt in den Papierkorb (nie endgültig) und braucht confirm: true nach Rückfrage.

Sicher überarbeiten

1. lit/post-duplicate → Entwurfskopie; die Antwort enthält die rev der Kopie für lit-content-update.
2. Kopie mit lit-content-update (oder den Divi-Tools) bearbeiten und dem Nutzer die Vorschau zeigen.
3. lit/post-replace-with-copy übernimmt die Kopie ins Original (ID, URL, Status und Menüeinträge bleiben). Voraussetzungen: die Kopie muss noch Entwurf oder ausstehend sein, rev des Originals aus lit-content-get ist Pflicht (sie deckt Titel, Inhalt, Auszug und Status ab – Felder/Meta, die direkt am Original geändert wurden, werden dabei überschrieben), und erst nach Rückfrage mit confirm: true aufrufen. Vorher entsteht eine Revision und eine vollständige Sicherung des bisherigen Originals im Papierkorb (backup_id in der Antwort); danach wandert die Kopie ebenfalls in den Papierkorb. Ist der Papierkorb der Website deaktiviert, wird der Austausch verweigert, statt die Kopie endgültig zu löschen.

Jede Änderung liefert log_id. Eine revision_id (Revision mit dem Stand vorher) liefern nur lit-content-update, lit/post-replace-with-copy und lit/revision-restore; bei allen anderen Tools ist sie null. Rückgängig: lit/revisions-list → lit/revision-restore mit der rev des Eintrags (aus lit-content-get) und confirm: true. Revisionen umfassen Titel, Inhalt und Auszug – Felder und Begriffe nicht (dafür bei lit/post-replace-with-copy die Sicherung backup_id).

Wenn ein Schreibvorgang fehlschlägt

Fehler stecken als JSON (code, message, hint, ggf. weitere Felder) in der Fehlermeldung. Schlägt ein Schreibvorgang nach ersten Änderungen fehl, ist code = write_failed (alles wurde zurückgenommen, nichts wurde gespeichert) oder partial_write (die Rücknahme war unvollständig). Bei partial_write vor einem erneuten Versuch immer erst den aktuellen Stand prüfen (lit-content-get, lit/menu-get o. Ä.) statt den Aufruf einfach zu wiederholen – dem hint folgen.