Tools-Referenz

Neleto stellt 43 MCP-Tools in 8 Kategorien bereit. Jeder Tool-Aufruf erfordert einen Authorization: Bearer <token>-Header.

Seiten

Tools zur Verwaltung von CMS-Seiten.

page_list

Alle verfügbaren Seiten im CMS auflisten.

page_get

Eine einzelne Seite mit Layout, Elementen und übersetztem Inhalt laden.

page_create

Eine neue Seite erstellen, inklusive Tags, Meta-Tags und Elementen.

page_update

Eine bestehende Seite aktualisieren. Gleiche Felder wie page_create, zusätzlich:

page_delete

Eine Seite soft-löschen.

page_duplicate

Eine Seite duplizieren mit neuem Pfad und Titel.

Layouts

Layouts sind wiederverwendbare Templates, die mehreren Seiten zugewiesen werden können.

layout_list

Alle Seiten-Layouts auflisten.

layout_get

Ein einzelnes Layout mit Elementbaum laden.

layout_create

Ein wiederverwendbares Layout mit Template, Style, Script und fixen Elementen erstellen.

layout_update

Ein bestehendes Layout aktualisieren. Gleiche Felder wie layout_create, zusätzlich:

layout_delete

Ein Layout soft-löschen.

Komponenten

Komponenten sind wiederverwendbare Bausteine, die Redakteure auf Seiten einfügen können.

component_list

Alle wiederverwendbaren CMS-Komponenten auflisten. Liefert pro Komponente eine schlanke Zusammenfassung (id, label, category, icon, canHaveChildren) — genug, um eine Komponente zu finden und ihre id günstig aufzulösen. Die vollständige Definition (template/style/script/form) mit component_get laden.

component_get

Eine einzelne Komponente anhand der ID laden.

component_search

Komponenten nach Form-Label suchen. Liefert dieselbe schlanke Zusammenfassung wie component_list.

component_used_by_elements

Alle Element-Instanzen auflisten, die eine Komponente verwenden.

component_create

Eine neue Komponente erstellen.

Bilder (Datei-Relationen). Ein Relationswert ist erst dann eine Datei, wenn du ihn bindest. Binde die Datei aus der Relation heraus und übergib die gebundene Datei zusammen mit einem erforderlichen Options-String an image_path. Ein Aufruf image_path(file) ohne Optionen oder das direkte Übergeben von relations.<id> ohne Binding ist ein harter Render-Fehler — kein leeres src:

{{#if relations.image as file}}
  <img src="{{ image_path(file, "w_1600,f_webp") }}" alt="{{ file.title }}">
{{/if}}

Das liefert /image/user-upload/<file-id>?options=w_1600,f_webp aus. Optionen sind kommagetrennt und werden der Reihe nach angewendet — s_<N> (quadratisch), w_<N>, h_<N>, f_webp|jpeg|png|avif|gif, q_<N> (JPEG-Qualität), e_<t>_<l>_<w>_<h> (Zuschnitt), fit_contain|fit_cover|fit_fill|fit_inside|fit_outside — siehe Image-Scaling. Andere Relations-Helper folgen derselben Bind-zuerst-Regel: post_path(post), event_path(event) und file_path(file) für Downloads. Für eine multiple-Relation mit {{#each relations.<id> as file}} … {{/each}} iterieren.

Builder-Formular-Property (Repeater). Eine builder-Property ist ein Repeater: Der Editor verwaltet ein Array von Zeilen, die alle dieselben Felder haben. Die JSON-Struktur ist leicht falsch zu treffen. Das items-Array der Property-Definition enthält genau einen Eintrag — eine einzelne Zeilen-Vorlage — und die Felder pro Zeile liegen im props-Array dieses Eintrags (nicht als separate items-Einträge):

{
    "id": "items",
    "type": "builder",
    "label": { "en": "Questions", "de": "Fragen" },
    "description": null,
    "hint": null,
    "required": null,
    "defaultValue": [
        { "id": "row1", "data": { "question": "...", "answer": "..." } },
        { "id": "row2", "data": { "question": "...", "answer": "..." } }
    ],
    "items": [
        {
            "id": "question",
            "type": "text",
            "name": "question",
            "label": { "en": "Item", "de": "Item" },
            "icon": null,
            "items": [],
            "data": "",
            "defaultValue": "",
            "property": { "type": "text", "defaultValue": "" },
            "props": [
                {
                    "id": "question",
                    "type": "textarea",
                    "label": { "en": "Question", "de": "Frage" },
                    "defaultValue": null,
                    "description": null,
                    "hint": null,
                    "required": null
                },
                {
                    "id": "answer",
                    "type": "textarea",
                    "label": { "en": "Answer", "de": "Antwort" },
                    "defaultValue": null,
                    "description": null,
                    "hint": null,
                    "required": null
                }
            ]
        }
    ]
}

• items = genau ein Zeilen-Vorlagen-Objekt. Die tatsächlichen Felder pro Zeile (question, answer, …) sind flache Property-Definitionen in dessen props-Array.
• Das Zeilen-Vorlagen-Objekt braucht weiterhin die Top-Level-Felder id, name, data, defaultValue, items ([]) und ein property-Objekt ({ type, defaultValue }). Strikt vom Deserializer verlangt werden label, name, data, props; der Rest spiegelt das, was der Admin-Builder-Konfigurationseditor erzeugt — mitschicken, damit die Definition sauber durch die UI läuft.
• Setze data und defaultValue der Zeilen-Vorlage auf "" (leerer String). Keinen echten Platzhalter-String verwenden: Beim Speichern verteilt der Admin-Builder-Editor die Zeichen eines nicht-leeren Strings als überflüssige numerische Schlüssel ({"0":"H","1":"o",…}) in die data jeder Zeile. Das bricht das Rendering nicht, beschädigt aber die gespeicherten Daten (bekannter Admin-UI-Bug); "" vermeidet das.
• Zeilenwerte — sowohl der Top-Level-defaultValue der Property als auch data[<propId>] jedes Elements — sind ein Array von { id, data }-Objekten, nicht ein flaches { fieldId: value } pro Zeile: [ { "id": "row1", "data": { "question": "…", "answer": "…" } } ].
• Im Template die Zeilenwerte über item.data.<fieldId> lesen (nicht item.<fieldId>):

{{#each properties.items as item}}
    {{item.data.question}}
    {{item.data.answer}}
{{/each}}

component_update

Eine bestehende Komponente aktualisieren. Gleiche Felder wie component_create, zusätzlich:

component_delete

Eine Komponente und alle verknüpften Element-Instanzen löschen.

Blogbeiträge

post_list

Blogbeiträge auflisten.

post_get

Einen Blogbeitrag anhand der ID laden.

post_search

Blogbeiträge nach Titel, Beschreibung oder Inhalt suchen.

post_create

Einen Blogbeitrag erstellen.

post_update

Einen Blogbeitrag aktualisieren. Gleiche Felder wie post_create, zusätzlich:

post_delete

Einen Blogbeitrag löschen.

Events

event_list

Events auflisten.

event_get

Ein Event anhand der ID laden.

event_search

Events nach Titel, Beschreibung oder Inhalt suchen.

event_today

Alle Events auflisten, die heute stattfinden.

Keine Parameter erforderlich.

event_upcoming

Bevorstehende Events auflisten.

Keine Parameter erforderlich.

event_create

Ein Event erstellen.

event_update

Ein Event aktualisieren. Gleiche Felder wie event_create, zusätzlich:

event_delete

Ein Event löschen.

Dateien

Datei-IDs sind UUIDs (Strings), keine Ganzzahlen.

file_list

Dateien und Ordner auflisten oder eine einzelne Datei mit Inhalt laden. Datei-Datensätze enthalten eine serveUrl — eine absolute …/image/user-upload/<id>-URL, welche die gespeicherten Bytes ausliefert.

file_get

Eine Datei mit Tags anhand der ID laden. Der Datensatz enthält eine serveUrl — eine absolute …/image/user-upload/<id>-URL, welche die gespeicherten Bytes ausliefert.

file_search

Dateien nach Titel, Beschreibung, Pfad, Status oder MIME-Typ suchen.

file_create

Eine Datei, einen Ordner oder einen Remote-Datei-Eintrag erstellen. Lokale Dateien werden leer auf dem Dateisystem angelegt.

file_upload

Eine Binärdatei oder ein Bild hochladen. Die Bytes werden auf eine von zwei Arten bereitgestellt: sourceUrl (eine http(s)-URL, die der Server selbst abruft) oder base64Data (Inline-base64). Genau eine ist erforderlich. Bei Erfolg enthält die Antwort die gespeicherte Byte-size sowie eine direkt nutzbare serveUrl (absolute …/image/user-upload/<id>-URL); diese URL akzeptiert zusätzlich Größenänderungen im Stil ?options=w_200,f_webp.

file_upload_begin / file_upload_chunk / file_upload_commit

Chunked-Upload für den Fall, dass die Bytes inline gesendet werden müssen (keine sourceUrl) und für einen einzelnen file_upload-Aufruf zu groß sind. Die Datei wird in kleinen base64-Stücken gestreamt und per SHA-256-Prüfsumme verifiziert, sodass eine beschädigte Übertragung laut fehlschlägt, statt Müll zu speichern.

Ablauf:

1. file_upload_begin mit Ziel-path (+ optional mimeType, status, title, description, metadata, tags, handleConflicts) → liefert { uploadId, maxBytes }.
2. file_upload_chunk wiederholt mit { uploadId, data } — data ist base64 (roh oder umbrochen) für das nächste Stück, in Reihenfolge. Stücke klein halten (etwa wenige KB Rohbytes), damit das base64 kurz genug ist, um es fehlerfrei auszugeben. Optional sha256 (Kleinbuchstaben-Hex der Rohbytes dieses Stücks) mitgeben; bei Nichtübereinstimmung wird nur dieses Stück abgelehnt. Liefert { receivedBytes }.
3. file_upload_commit mit { uploadId, sha256 } (Kleinbuchstaben-Hex der gesamten Datei, plus optional totalSize) → der Server setzt zusammen, verifiziert, speichert die Datei und liefert dieselbe { size, serveUrl, … }-Antwort wie file_upload.
4. file_upload_abort mit { uploadId } (optional) → verwirft einen unvollständigen Upload samt Temp-Datei, wenn er nicht abgeschlossen werden kann. Eine unbekannte oder bereits abgeschlossene uploadId ist ein No-op.

Uploads, die eine Stunde lang inaktiv bleiben (kein Commit und kein neuer Chunk), werden automatisch entfernt; übrig gebliebene Temp-Dateien werden beim Neustart des Servers aufgeräumt. Chunks müssen vom selben Benutzer gesendet werden, der den Upload begonnen hat.

file_update

Datei-Metadaten oder den Inhalt einer lokalen Datei aktualisieren.

file_delete

Eine oder mehrere Dateien bzw. Ordner löschen.

file_move

Dateien in einen anderen Ordnerpfad verschieben oder kopieren.

file_rename

Eine Datei oder einen Ordner umbenennen (letztes Pfadsegment ändern).

Web-Dateien

Web-Dateien sind statische Textdateien, die im Root deiner Website bereitgestellt werden (z.B. /sitemap.xml, /llms.txt, /llms-full.txt). Jede Datei hat einen eindeutigen Pfad, einen rohen Textinhalt und einen MIME-Content-Type, der aus der Dateiendung abgeleitet wird.

web_file_list

Listet alle Web-Dateien auf.

Keine Parameter erforderlich.

web_file_get

Lädt eine einzelne Web-Datei anhand des Pfads.

web_file_create

Erstellt eine neue Web-Datei, die unter /<path> erreichbar ist.

web_file_update

Aktualisiert den Inhalt einer bestehenden Web-Datei anhand des Pfads.

web_file_delete

Löscht eine Web-Datei anhand des Pfads.

Einstellungen

settings_get

CMS-Einstellungen mit aufgelösten Seitenreferenzen und Meta-Tags laden. Die Antwort liefert außerdem die öffentlichen URLs der Live-Instanz, damit ein Agent die von ihm erstellte Website per Screenshot prüfen kann:

• publicBaseUrl — der Host, unter dem die Website ausgeliefert wird (z.B. https://yannik.free.neleto.io).
• imageBaseUrl — das Präfix, unter dem hochgeladene Dateien ausgeliefert werden (z.B. …/image/user-upload).
• adminUrl — die Editor-URL.

settings_update

CMS-Einstellungen aktualisieren. Alle Felder sind optional - nur angegebene Felder werden geändert.