Tools Reference

Neleto exposes 43 MCP tools across 8 categories. Each tool call requires an Authorization: Bearer <token> header.

Pages

Tools for managing CMS pages.

page_list

List pages available in the CMS.

page_get

Load a single page with its layout, elements, and translated content.

page_create

Create a new page including tags, meta tags, and elements.

page_update

Update an existing page including its nested elements. Same fields as page_create plus:

page_delete

Soft-delete a page.

page_duplicate

Duplicate a page to a new route and title.

Layouts

Layouts are reusable templates that can be assigned to multiple pages.

layout_list

List page layouts.

layout_get

Load a single layout with its element tree.

layout_create

Create a reusable layout with template, style, script, and fixed elements.

layout_update

Update an existing layout including its element tree. Same fields as layout_create plus:

layout_delete

Soft-delete a layout.

Components

Components are reusable building blocks that editors can insert on pages.

component_list

List all reusable CMS components. Returns a lightweight summary per component (id, label, category, icon, canHaveChildren) — enough to find a component and resolve its id cheaply. Load a component's full definition (template/style/script/form) with component_get.

component_get

Load a single component by ID.

component_search

Search components by form label. Returns the same lightweight summary shape as component_list.

component_used_by_elements

List all element instances that use a given component.

component_create

Create a new component.

Images (file relations). A relation value is not a file until you bind it. Bind the file out of the relation, then pass the bound file to image_path together with a required options string. Calling image_path(file) with no options, or passing relations.<id> unbound, is a hard render error — not an empty src:

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

This serves /image/user-upload/<file-id>?options=w_1600,f_webp. Options are comma-separated and applied in order — s_<N> (square), w_<N>, h_<N>, f_webp|jpeg|png|avif|gif, q_<N> (jpeg quality), e_<t>_<l>_<w>_<h> (crop), fit_contain|fit_cover|fit_fill|fit_inside|fit_outside — see image scaling. Other relation helpers follow the same bind-first rule: post_path(post), event_path(event), and file_path(file) for downloads. For a multiple relation, iterate with {{#each relations.<id> as file}} … {{/each}}.

Builder (repeater) form property. A builder property is a repeater: the editor manages an array of rows that all share the same fields. Its JSON shape is easy to get wrong. The property definition's items array holds exactly one entry — a single row template — and the per-row fields live inside that entry's props array (not as separate items entries):

{
    "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 = exactly one row-template object. The real per-row fields (question, answer, …) are plain flat property definitions inside its props array.
• The row-template object still needs top-level id, name, data, defaultValue, items ([]), and a property object ({ type, defaultValue }). Strictly required by the deserializer are label, name, data, props; the rest mirror what the admin Builder Configuration editor emits — include them so the definition round-trips through the UI.
• Set the row-template's data and defaultValue to "" (empty string). Do not use a real placeholder string: on save the admin builder editor spreads a non-empty string's characters into every row's data as stray numeric keys ({"0":"H","1":"o",…}). It doesn't break rendering but corrupts the stored data (known admin-UI bug); "" avoids it.
• Row values — both the property's top-level defaultValue and each element's data[<propId>] — are an array of { id, data } objects, not a flat { fieldId: value } per row: [ { "id": "row1", "data": { "question": "…", "answer": "…" } } ].
• In the template, read row values via item.data.<fieldId> (not item.<fieldId>):

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

component_update

Update an existing component. Same fields as component_create plus:

component_delete

Delete a component and all element instances linked to it.

Blog Posts

post_list

List blog posts.

post_get

Load a blog post by ID.

post_search

Search posts by title, description, or content.

post_create

Create a blog post.

post_update

Update a blog post. Same fields as post_create plus:

post_delete

Delete a blog post.

Events

event_list

List events.

event_get

Load an event by ID.

event_search

Search events by title, description, or content.

event_today

List all events happening today.

No parameters required.

event_upcoming

List upcoming events.

No parameters required.

event_create

Create an event.

event_update

Update an event. Same fields as event_create plus:

event_delete

Delete an event.

Files

File IDs are UUIDs (strings), not integers.

file_list

List files, folders, or load a single file with optional content. File records include a serveUrl — an absolute …/image/user-upload/<id> URL that serves the stored bytes.

file_get

Load a file with its tags by ID. The record includes a serveUrl — an absolute …/image/user-upload/<id> URL that serves the stored bytes.

file_search

Search files by title, description, path, status, or MIME type.

file_create

Create a file, folder, or remote file entry. Local files are created empty on disk.

file_upload

Upload a binary file or image. Provide the bytes one of two ways: sourceUrl (an http(s) URL the server fetches itself) or base64Data (inline base64). Exactly one is required. On success the response includes the stored byte size and a ready-to-use serveUrl (absolute …/image/user-upload/<id> URL); that URL also accepts ?options=w_200,f_webp-style resizing.

file_upload_begin / file_upload_chunk / file_upload_commit

Chunked upload for when you must send bytes inline (no sourceUrl) and they're too large to survive a single file_upload call. The file is streamed in small base64 slices and verified with a SHA-256 checksum, so a corrupt transfer fails loudly instead of storing garbage.

Flow:

1. file_upload_begin with the destination path (+ optional mimeType, status, title, description, metadata, tags, handleConflicts) → returns { uploadId, maxBytes }.
2. file_upload_chunk repeatedly with { uploadId, data } — data is base64 (raw or whitespace-wrapped) for the next slice, in order. Keep chunks small (roughly a few KB of raw bytes) so the base64 is short enough to emit without drift. Optionally pass sha256 (lowercase hex of that chunk's raw bytes); a mismatch rejects just that chunk. Returns { receivedBytes }.
3. file_upload_commit with { uploadId, sha256 } (lowercase hex of the whole file, plus optional totalSize) → the server reassembles, verifies, stores the file, and returns the same { size, serveUrl, … } payload as file_upload.
4. file_upload_abort with { uploadId } (optional) → discards a partial upload and its temp file when it can't be finished. An unknown or already-finished uploadId is a no-op.

Uploads that stay idle for an hour (no committed and no new chunk) are swept automatically, and any leftover temp files are cleaned up on server restart. Chunks must be sent by the same user that began the upload.

file_update

Update file metadata or content for local files.

file_delete

Delete one or more files or folders.

file_move

Move or copy files into another folder path.

file_rename

Rename a file or folder by changing the last segment of its path.

Web Files

Web files are static text files served at the root of your site (e.g. /sitemap.xml, /llms.txt, /llms-full.txt). Each file has a unique path, raw text content, and a MIME content type derived from the path's extension.

web_file_list

List all web files.

No parameters required.

web_file_get

Get a single web file by path.

web_file_create

Create a new web file served at /<path>.

web_file_update

Update the content of an existing web file by path.

web_file_delete

Delete a web file by path.

Settings

settings_get

Load CMS settings with resolved page references and meta tags. The response also exposes the live instance's public URLs, so an agent can screenshot or verify the site it builds:

• publicBaseUrl — the host the site is served from (e.g. https://yannik.free.neleto.io).
• imageBaseUrl — the prefix served uploads live under (e.g. …/image/user-upload).
• adminUrl — the editor URL.

settings_update

Update CMS settings. All fields are optional - only provided fields are changed.