Integrierte MCP-Server

Facets bilden in CLYE die semantische Verbindung zwischen Wissen, MCP-Tools und Prozesslogik. Wie dieses Architekturprinzip funktioniert, zeigt der Architekturvergleich von Facets, MCP-Tools und Tasks/Events. Integrierte MCP-Server sind eingebaute Fähigkeiten des CLYE AI. Sie verhalten sich für Assistenten ähnlich wie angebundene MCP-Server, kommen aber direkt aus dem Produkt und brauchen oft keine externe Verbindung.

Ein integrierter MCP-Server erweitert, was ein Assistent tun kann oder wie er Informationen darstellt.

Wo du sie findest

Je nach Bereich findest du diese Fähigkeiten meist in den Einstellungen eines Assistenten unter MCP-Server, Werkzeuge, Integrationen oder einem ähnlichen Punkt.

Ob du sie sehen oder anpassen kannst, hängt von drei Dingen ab:

deinem Kontext, also persönlicher Bereich oder gemeinsamer Bereich
deiner Rolle
eurer Freischaltung im Setup

Wann ein integrierter MCP-Server sinnvoll ist

Aktiviere solche Fähigkeiten nur dann, wenn sie im Alltag einen klaren Nutzen haben. Gute Gründe sind:

ein Assistent soll Antworten anders darstellen
ein Assistent soll gezielter auf Wissen zugreifen
ein Assistent soll sich Dinge dauerhaft merken
ein Assistent soll aktuelle Web-Inhalte einbeziehen

Wenn ein normaler Chat mit guter Frage und passender Ablage schon reicht, brauchst du meist keinen zusätzlichen integrierten MCP-Server.

Wie du sie im Alltag sinnvoll auswählst

Eine einfache Denkweise hilft:

Darstellung: Wie soll die Antwort aussehen?
Wissen: Worauf soll der Assistent zugreifen?
Dauerhaftigkeit: Was soll er sich über Sitzungen hinweg merken?
Aktualität: Braucht er Informationen aus dem Web?

Typische integrierte MCP-Server

MDX im Chat für interaktive Antworten mit Karten, Tabs, Formularen oder Diagrammen
Ablage-Suche (RAG) für Wissen aus Ablagen, Spaces und gepflegten Inhalten
Memory für dauerhafte Notizen, Präferenzen und stabilen Kontext
Web und Browser für aktuelle Informationen und gezieltes Öffnen von Webseiten
Automationen und Code für wiederkehrende Abläufe und sichere JS/TS-Ausführung mit Dateien, Tools und Event-Logik

Für einen vollständigen, technischeren Überblick über alle eingebauten Server inklusive ihrer Eignung als Automation Action siehe:

Katalog der integrierten MCP-Server

Gute Einführungsreihenfolge

Starte mit Ablage-Suche (RAG), wenn Wissen aus dem CLYE AI genutzt werden soll.
Ergänze Memory, wenn sich ein Assistent Dinge dauerhaft merken soll.
Nutze MDX im Chat, wenn Antworten visuell oder interaktiv werden sollen.
Schalte Web und Browser dazu, wenn aktuelle Informationen wirklich nötig sind.
Nutze Automationen und Code, wenn ihr wiederkehrende Abläufe sauber automatisieren oder Tool-Ketten zuverlässig ausführen wollt.

Was du vermeiden solltest

aktiviere nicht alles auf einmal
verwechsel gute Darstellung nicht mit fachlich gutem Inhalt
erwarte von Web-Funktionen keine Freigabe für ungeprüfte Aussagen
lagere dauerhaftes Wissen nicht allein in Chats aus, wenn es in eine Ablage gehört

Kurz gesagt

Integrierte MCP-Server sind eingebaute Zusatzfähigkeiten für Assistenten. Sie sind dann wertvoll, wenn sie eine konkrete Lücke schließen: bessere Darstellung, besseres Auffinden von Wissen, dauerhaftes Merken oder aktueller Web-Zugriff.

MDX im Chat

MDX im Chat erlaubt es einem Assistenten, Antworten nicht nur als Fließtext, sondern als strukturierte Oberfläche im Chat darzustellen. Dazu gehören zum Beispiel Karten, Tabs, Accordions, Formulare oder einfache Diagramme. Zusätzlich stehen jetzt auch präsentationsorientierte MDX-Bausteine wie Score, KPI, Deadline, Pipeline, Accordion und Tabs zur Verfügung, wenn ein Assistent Ergebnisse im Chat klarer strukturieren soll.

Wofür MDX im Chat gut ist

Dieser integrierte MCP-Server ist besonders nützlich, wenn Antworten übersichtlicher oder interaktiver werden sollen.

Typische Fälle:

strukturierte Zusammenfassungen
Vergleichsansichten mit Karten oder Tabs
kleine Formulare für Rückfragen
editierbare E-Mail-Entwürfe mit Empfängern, Betreff und optionalen Varianten
Diagramme für Zahlen, Trends oder Verteilungen
klar gegliederte Handlungsoptionen

Wann du ihn einschalten solltest

MDX lohnt sich vor allem dann, wenn der Assistent nicht nur antworten, sondern Ergebnisse besser präsentieren soll.

Das ist besonders hilfreich, wenn:

mehrere Informationsblöcke gleichzeitig verständlich bleiben sollen
Nutzer schnell zwischen Ansichten wechseln sollen
Zahlen nicht nur als Tabelle, sondern als Grafik gezeigt werden sollen
Rückfragen direkt über ein Formular gesammelt werden sollen

Wann normaler Text oft besser ist

Nicht jede Antwort braucht eine Oberfläche.

Gewöhnlicher Chat-Text reicht meist aus, wenn:

die Antwort kurz und eindeutig ist
nur eine schnelle Rückfrage beantwortet werden soll
keine Auswahl, Struktur oder visuelle Führung nötig ist

So fragst du sinnvoll danach

Hilfreich sind klare Wünsche zur Darstellung, zum Beispiel:

zeige das als Karten mit je einer Empfehlung
stelle die Unterschiede in Tabs dar
erstelle einen bearbeitbaren E-Mail-Entwurf mit To, CC, Betreff und Nachrichtentext
fasse die Zahlen als kleines Diagramm zusammen
gib mir ein Formular mit den drei Rückfragen, die noch offen sind

Woran du gute Ergebnisse erkennst

die Darstellung hilft beim Verstehen statt nur dekorativ zu sein
jede Karte oder Sektion hat einen klaren Zweck
Formulare fragen nur wirklich notwendige Dinge ab
Diagramme zeigen nur Daten, die für die Entscheidung relevant sind

Wenn eine Antwort Mermaid-Diagramme oder hervorgehobene Code-Blöcke enthält, bleibt diese Darstellung jetzt auch erhalten, wenn du den Chat später erneut öffnest. Du musst solche Inhalte also nicht neu erzeugen, nur um sie wieder als Diagramm oder mit Syntax-Highlighting zu sehen.

Gute erste Einsatzfälle

Meeting-Ergebnisse als Karten mit nächsten Schritten darstellen
Optionen in Tabs gegenüberstellen
ein Prüf-Ergebnis als Ampel oder strukturierte Übersicht zeigen
einfache Datensätze als Balken- oder Linienchart visualisieren

Ein praktisches Beispiel sind Routen-Karten im Chat: Wenn ein Assistent zu einer Strecke passende Geometriedaten hat, kann MDX den Verlauf direkt als Route auf einer Karte darstellen statt nur einen Kartenausschnitt oder einen einzelnen Marker zu zeigen. Das ist besonders hilfreich bei längeren oder schmalen Nord-Süd-Strecken, die in einfachen Embed-Karten sonst schwer lesbar wären.

Wichtig für längere Folgegespräche: Solche MDX-Routen-Karten bleiben im sichtbaren Chat erhalten, werden für spätere Modellaufrufe aber intern kompakter repräsentiert. Große Geometrie-Blöcke aus älteren Antworten blähen den Modellkontext dadurch nicht unnötig auf. Ein weiteres praktisches Beispiel sind E-Mail-Entwürfe als MDX-Karte. Wenn du im Chat um das Formulieren oder Entwerfen einer E-Mail bittest, kann ein Assistent dafür direkt eine bearbeitbare E-Mail-Entwurfskarte ausgeben. Sie zeigt dir An, CC, BCC, Betreff und Nachrichtentext direkt im Chat an. Standardmäßig enthält die Karte eine einzelne bearbeitbare Fassung. Nur wenn du ausdrücklich mehrere Alternativen möchtest, können zusätzlich Stil-Varianten wie freundlich, kurz oder förmlich als Tabs erscheinen. Du kannst die Inhalte vor dem Versand anpassen, den Entwurf per Klick kopieren oder über Senden als mailto:-Link in dein Mailprogramm übernehmen. Wenn der Nachrichtentext Markdown enthält, zeigt die Karte diesen Inhalt zunächst als formatierte Vorschau an. Zum Bearbeiten klickst du einfach in die Vorschau; dann öffnet sich wieder der Rohtext. So lässt sich ein Entwurf leichter gegenlesen, ohne dass Listen, Hervorhebungen oder Absätze erst im eigenen Mailprogramm sichtbar werden. Wenn der Link sehr lang wird, weist CLYE AI zusätzlich darauf hin, dass manche Mailprogramme lange mailto:-Links abschneiden können. CLYE AI rendert solche E-Mail-Entwurfskarten jetzt außerdem robuster, auch wenn bei Varianten im MDX-Tag ein abschließendes einfaches Anführungszeichen fehlt.

Grenzen im Alltag

MDX verbessert vor allem die Form der Antwort. Es ersetzt nicht:

saubere Datenbasis
gepflegtes Wissen in der Ablage
fachliche Prüfung
gute Aufgaben- oder Freigabeprozesse

Kurz gesagt

Nutze MDX im Chat, wenn ein Assistent Ergebnisse sichtbar strukturieren oder interaktiv darstellen soll. Für kurze, direkte Antworten bleibt normaler Chat-Text meist die bessere Wahl.

Ablage-Suche (RAG)

Die Ablage-Suche (RAG) hilft einem Assistenten, passende Inhalte aus Ablagen, Spaces und gepflegtem Wissen im CLYE AI zu finden und in Antworten einzubeziehen.

Wofür RAG im Alltag da ist

RAG ist besonders nützlich, wenn der Assistent nicht nur allgemein antworten, sondern mit eurem vorhandenen Wissen arbeiten soll.

Typische Fälle:

Richtlinien, Vorlagen oder Projektdokumente einbeziehen
Wissen aus einem Team-Space nutzen
bestehende Notizen oder Dateien wiederfinden
relevante Inhalte aus der Ablage statt aus dem freien Web verwenden

Woran du erkennst, dass RAG hilft

RAG ist oft die richtige Wahl, wenn du denkst:

das müsste doch schon in unserer Ablage liegen
der Assistent soll sich auf unsere Unterlagen stützen
ich will nichts neu hochladen, weil es schon im Space vorhanden ist

Im Chat ist dafür oft die Funktion Ablage durchsuchen der schnellste Einstieg.

Was du dafür vorbereiten solltest

RAG funktioniert am besten, wenn Wissen gut gepflegt ist:

Dateien liegen am passenden Ort
Titel und Inhalte sind verständlich benannt
veraltete Dokumente werden entfernt oder ersetzt
wichtige Hinweise stehen nicht nur verstreut in alten Chats

So nutzt du RAG gut

Hilfreiche Formulierungen sind zum Beispiel:

beantworte das auf Basis unserer Ablage
nutze nur Inhalte aus dem Projekt-Space
suche in den vorhandenen Unterlagen nach den wichtigsten Unterschieden
stütze dich nur auf die abgelegten Richtlinien

Zusätzlicher Suchbereich für Assistenten

In den Werkzeug-Einstellungen eines Assistenten kann für die Ablage-Suche (RAG) zusätzlich die Option Alle Gruppen und Spaces durchsuchen verfügbar sein.

Wenn diese Option aktiviert ist, sucht rag_search nicht nur im bisherigen Bereich des Assistenten, sondern zusätzlich in allen Gruppen und Spaces, in denen die anfragende Person Mitglied ist.

Wichtig dabei:

berücksichtigt werden nur Gruppen und Spaces, in denen die anfragende Person Mitglied ist
Inhalte aus Bereichen ohne Mitgliedschaft werden nicht einbezogen
Assistenten-Spaces werden dabei nicht zusätzlich durchsucht
wenn die Option deaktiviert ist, bleibt die Suche auf den bisherigen Suchbereich beschränkt
eine explizite @-Erwähnung einer passenden Gruppe kann die Suche zusätzlich auf genau diesen freigegebenen Bereich ausweiten

Das gilt auch dann, wenn rag_search intern nicht direkt, sondern über call_tool ausgelöst wird. So kann ein Assistent ein Dokument aus einer ausdrücklich erwähnten Gruppe auch dann finden, wenn der Assistent selbst dort kein Mitglied ist und ohne diese Erwähnung keinen Zugriff über die normale Suche hätte.

Diese Einstellung ist vor allem dann nützlich, wenn Wissen bewusst über mehrere Team-Bereiche verteilt liegt und der Assistent trotzdem breiter im freigegebenen Kontext recherchieren soll. Die explizite @-Erwähnung ist zusätzlich hilfreich, wenn du eine Suche gezielt auf eine bestimmte Gruppe lenken willst.

Wann RAG besser ist als Web oder Chat-Dateien

RAG ist besser, wenn relevantes Wissen schon im CLYE AI liegt.
Web ist besser, wenn aktuelle externe Informationen gebraucht werden.
Chat-Dateien sind besser, wenn eine einmalige Datei nur für diesen Chat wichtig ist.

Typische Grenzen

RAG ist keine Garantie dafür, dass automatisch immer das richtige Dokument priorisiert wird. Gute Ergebnisse hängen auch davon ab:

wie klar du fragst
wie sauber der Wissensbereich gepflegt ist
ob die wirklich relevanten Inhalte überhaupt in der Ablage vorhanden sind

Gute erste Einsatzfälle

Antwort auf Basis interner Richtlinien erzeugen
einen bestehenden Standard aus der Ablage auf einen Fall anwenden
relevante Stellen in vorhandenen Dokumenten zusammenfassen
Vorlagen und Teamwissen in neue Entwürfe einfließen lassen

Kurz gesagt

Nutze Ablage-Suche (RAG) immer dann, wenn ein Assistent euer vorhandenes Wissen aus dem CLYE AI verwenden soll. Je besser die Ablage gepflegt ist, desto verlässlicher werden die Ergebnisse.

Memory

Memory erlaubt es einem Assistenten, sich dauerhafte Informationen zu merken. Dazu können Präferenzen, wiederkehrende Regeln, stabile Hintergründe oder wichtige Arbeitsweisen gehören.

Wofür Memory gut ist

Memory ist sinnvoll für Informationen, die nicht nur in einem einzelnen Chat gelten, sondern länger relevant bleiben.

Typische Beispiele:

bevorzugter Stil oder Ton
feste Begriffe oder Schreibweisen
wiederkehrende Anforderungen eines Teams
stabile Hintergründe zu Projekten oder Rollen

Wann du Memory statt normalen Chat-Kontext nutzen solltest

Ein normaler Chat reicht, wenn etwas nur für den aktuellen Verlauf wichtig ist.

Memory ist besser, wenn:

dieselbe Information später wieder gebraucht wird
du nicht bei jedem Chat von vorn erklären willst
ein Assistent dauerhaft konsistent reagieren soll

Was sich gut merken lässt

klare Präferenzen
wiederkehrende Regeln
stabile Fakten mit längerem Nutzen
kurze, verständliche Arbeitskontexte

Was du besser nicht in Memory legst

flüchtige Zwischenstände
unklare Vermutungen
sehr lange Rohtexte
Inhalte, die eigentlich in eine gepflegte Ablage gehören

Wenn Wissen für mehrere Personen oder Prozesse wichtig ist, bleibt ein Space oft der bessere Hauptort. Memory ergänzt diesen Kontext, ersetzt ihn aber nicht.

So nutzt du Memory sinnvoll

Formuliere kurz und eindeutig, was sich der Assistent merken soll. Gute Beispiele sind:

merke dir, dass ich Antworten eher kurz und direkt möchte
merke dir unsere feste Produktbezeichnung
merke dir die Prüfreihenfolge für diese Art von Anfrage

Woran du gutes Memory erkennst

die Information bleibt auch in einigen Tagen noch nützlich
sie ist konkret und verständlich
sie führt zu sichtbar konsistenteren Antworten
sie erzeugt keine unnötigen Dubletten zu bestehendem Space-Wissen

Memory prüfen und pflegen

Je nach Bereich findest du gespeicherte Notizen auch direkt in der Ablage unter Memory. Dort lässt sich besser prüfen, was dauerhaft gepflegt werden sollte und was wieder raus kann.

Wichtig für Assistenten-Spaces: Die eigenen dauerhaften Memories eines Assistenten werden in seinem Assistenten-Space gepflegt. Ein Chat oder eine Aufgabe in einem anderen Space kann zwar Sichtbarkeit und Zugriff beeinflussen, verlegt diese dauerhaften Assistenten-Memories aber nicht automatisch in den gerade sichtbaren Arbeitskontext.

Spätestens wenn ein Assistent sich wiederholt auf veraltete oder zu spezielle Dinge stützt, solltest du Memory bereinigen.

Kurz gesagt

Nutze Memory für dauerhafte, kompakte Informationen, die ein Assistent über mehrere Chats hinweg konsistent berücksichtigen soll. Für umfangreiches Teamwissen bleibt ein Space die bessere Grundlage.

Web und Browser

Der integrierte MCP-Server Web und Browser hilft Assistenten dabei, aktuelle Informationen aus dem Web einzubeziehen oder konkrete Webseiten gezielt zu öffnen und durchzugehen.

Der einfache Unterschied

Web ist für Suchen und aktuelle Informationen gedacht.
Browser ist für gezieltes Öffnen und Durchgehen einzelner Seiten gedacht.

Wann du Web nutzen solltest

Web ist sinnvoll, wenn Informationen außerhalb eurer Ablage liegen oder aktuell sein müssen.

Typische Fälle:

neue Entwicklungen prüfen
externe Websites, Anbieter oder Veröffentlichungen vergleichen
schnell aktuelle Fakten nachschlagen
Ergänzungen finden, die nicht im Space liegen

Wann Browser zusätzlich hilft

Browser ist besonders nützlich, wenn eine Antwort nicht nur auf Suchtreffern beruhen soll, sondern eine konkrete Seite wirklich angesehen werden muss.

Das ist hilfreich, wenn:

eine bestimmte Unterseite geprüft werden soll
Inhalte auf einer Seite genauer nachvollzogen werden müssen
mehrere Schritte auf einer Website verständlich beschrieben werden sollen

Wann du stattdessen lieber RAG nutzt

Wenn das relevante Wissen schon im CLYE AI liegt, ist Ablage-Suche (RAG) meist besser als Web.

Web ist eher der richtige Weg, wenn:

Informationen außerhalb eures Systems liegen
Aktualität entscheidend ist
externe Quellen bewusst einbezogen werden sollen

So formulierst du gute Anfragen

Hilfreich sind klare Hinweise wie:

prüfe den aktuellen Stand dazu im Web
vergleiche drei aktuelle externe Quellen
öffne die konkrete Seite und erkläre die wichtigsten Schritte
nutze nur aktuelle Web-Quellen und fasse die Unterschiede zusammen

Woran du gute Ergebnisse erkennst

der Assistent trennt klar zwischen internem Wissen und Web-Quellen
aktuelle Informationen werden nicht als zeitlos dargestellt
Ergebnisse bleiben überprüfbar
die Antwort nennt klar, worauf sie sich stützt

Wichtige Grenze

Web und Browser liefern zusätzliche Informationen, aber keine automatische Freigabe für Richtigkeit. Besonders bei wichtigen Aussagen gilt weiterhin:

Quellen prüfen
Datum und Kontext beachten
kritische Aussagen fachlich gegenlesen

Kurz gesagt

Nutze Web, wenn aktuelle externe Informationen gebraucht werden, und Browser, wenn eine konkrete Seite wirklich durchgegangen werden soll. Für internes Wissen bleibt RAG meist der bessere erste Schritt.

Code ausführen (Tool `js_execute`, integrierter MCP-Server „JS“)

Der integrierte MCP-Server JS erweitert Assistenten um zwei zentrale Fähigkeiten:

Automationen ausführen: wiederkehrende Abläufe zuverlässig nach Ereignissen oder Zeitplänen anstoßen.
Code-Tool: kleine TypeScript/JavaScript-Skripte sicher in einer isolierten Umgebung ausführen, um Daten zu verarbeiten oder Aktionen zu orchestrieren.

Diese Seite erklärt, was du damit als Endnutzer tun kannst, und welche Funktionen dir im Code-Tool zur Verfügung stehen.

Wann ist der JS-Server sinnvoll?

Nutze ihn, wenn du:

Daten aus Dateien/Ergebnissen transformieren willst (z. B. Liste bereinigen, Felder normieren, JSON erzeugen).
Tools kombinieren willst (z. B. erst suchen, dann Ergebnisse filtern, dann als Datei speichern).
aus einem Trigger heraus Folgeschritte durchführen willst (z. B. „Wenn X passiert, lege Einträge an, schreibe eine Zusammenfassung, speichere Artefakte“).

Wenn du nur eine normale Frage beantwortet haben willst, ist der JS-Server meist nicht nötig.

Gerade für effiziente Automationen ist der Server wichtig, weil du mit Code erst die billigen Schritte erledigen kannst: prüfen, filtern, deduplizieren, Felder normalisieren, Relevanz entscheiden. Ein LLM-Aufruf sollte erst danach kommen, wenn wirklich ein inhaltlicher KI-Schritt nötig ist.

Beziehung zu Automation Actions

Der Name ist etwas irreführend: Das Code-Tool läuft über den integrierten MCP-Server JS ist nicht nur für klassische Trigger-Automationen relevant, sondern auch selbst eine Quelle für Tools, die als Aktion in Automationen auftauchen können.

Das heißt praktisch:

In einer Automation kann als Aktion ein Tool aus dem Server JS gewählt werden.
Dazu gehören vor allem Such-, Patch- und Code-Ausführungswerkzeuge.
Daneben können auch viele andere integrierte MCP-Server als Aktion dienen, zum Beispiel chat/send_message, event/event_dispatch, email/email_send oder task_management/task_create.

Mehr dazu:

Katalog der integrierten MCP-Server
Aktionen

Das Tool `js_execute` (JS/TS in der Sandbox ausführen)

js_execute führt TypeScript/JavaScript in einer Sandbox aus. Wenn dabei ein Fehler passiert, ordnet CLYE AI die Meldung jetzt besser deinem eigenen Skript zu: Statt interner Host-Dateien oder wenig hilfreicher Sandbox-Positionsangaben siehst du typischerweise die relevante Stelle im Editor-Code, oft zusammen mit einem Ausschnitt und einem besser lesbaren Trace. Timeouts erscheinen als klare Skript-Timeout-Meldung mit Hinweis auf das Limit. Bereits berechnete Ergebnisse oder echte Skriptfehler werden außerdem nicht mehr durch einen nachgelagerten QuickJS-Dispose-Abbruch mit internem WASM-Assert ersetzt.

js_execute führt TypeScript/JavaScript in einer Sandbox aus:

Große Rückgaben kann CLYE AI im normalen Fall zusätzlich als Vollausgaben oder Artefakte im laufenden Thread ablegen. Falls dieses Ablegen in einem Aufgaben-Thread einmal scheitert, gilt der eigentliche Tool-Aufruf trotzdem nicht als komplett fehlgeschlagen: Das Ergebnis bleibt in gekürzter Form nutzbar und enthält bei Bedarf einen Hinweis auf den Ablagefehler.

keine Shell-Befehle, kein direkter Systemzugriff
Virtuelles Dateisystem (fs) und mcp/help nur im Chat- und Playground-Profil (siehe Zwei Modi)
MCP im klassischen Automations-Hintergrund z. B. über tools.call_tool({ name, server, arguments }), über direkte tools.<name>(...)-Aufrufe oder per import { callMcpTool } from "clye.ai"
Hilfsfunktionen für Events, Wissens-/Chunk-Operationen und (profilabhängig) fetch; Datum/JSON wie gewohnt über Standard-JavaScript (new Date(), JSON.*) bzw. über die in help() gelisteten Projekt-APIs
zusätzlich upload(input, options?), wenn dein Skript Dateien direkt in den aktuellen CLYE-Kontext hochladen soll

Zwei Modi: Chat vs. Automation (wichtig)

Je nachdem, wo du Code ausführst, gelten unterschiedliche Regeln:

Im Chat (interaktiver Lauf, z. B. Tool „JS/TS im Chat ausführen“)
- fs, mcp und help stehen als Globals zur Verfügung (virtuelles Dateisystem).
- Dateien liegen im Chat-Kontext (Uploads + Workspace).
- HTTP/fetch ist bewusst deaktiviert (damit kein unkontrollierter Netzwerkzugriff aus der Sandbox passiert).
- Bei addChunks: die Variante url: { fetch: "…" } (Host lädt eine URL nach) ist im gleichen Profil ebenfalls deaktiviert. Normale URL-Strings, data:-URLs sowie Blob/ArrayBuffer/Uint8Array funktionieren weiterhin.
Im Space-JS-Playground
- Wie Chat: fs, mcp, help; kein freies fetch; addChunks ohne { fetch: … }.
- Für Space-MCP-Server nutzt der Playground jetzt den laufenden Space als Basis. Installationen aus dem gerade geöffneten Space stehen dadurch auch dann zuverlässig zur Verfügung, wenn dein persönlicher Assistent oder API-Key zu einem anderen Home-Space gehört.
- In persönlichen Sandboxes bleibt die MCP-Session zusätzlich am Space deines API-Keys gebunden. Dadurch findet dein persönlicher Chat dieselbe MCP-Runtime zuverlässig wieder, statt versehentlich an einen anderen Assistenten-Space zu geraten.
- Wenn eine bestehende persönliche Sandbox vor dieser Umstellung gestartet wurde, starte sie einmal neu, damit die Session am richtigen Space hängt.
In einer klassischen Automation (Hintergrundlauf ohne Chat-Kontext)
- fs, mcp und help gibt es hier nicht als Globals (kein Chat-Dateisystem in diesem Profil).
- fetch ist möglich, wenn eure Umgebung das zulässt.
- addChunks darf url: { fetch: "…", … } nutzen (Host lädt die URL und legt die Datei ab).
- Typisch nutzt du tools.*, Events (lastEvent / getEvents), Chunk-Helfer, import … from "clye.ai", console und das Objekt automation (siehe unten).

Dateien direkt aus `js_execute` hochladen (`upload`)

Mit upload(input, options?) kannst du aus js_execute heraus Dateien direkt in CLYE hochladen, ohne erst manuell einen Chat-Anhang oder einen separaten Import-Schritt anzulegen.

Das ist besonders nützlich, wenn dein Skript:

eine Datei von einer URL übernehmen soll
Text oder Base64 erst im Code erzeugt und danach als Datei speichern soll
Binärdaten aus einer API-Antwort, einem Blob, Response oder Uint8Array direkt als Datei ablegen soll
aus einem Automation-Lauf einen normalen Datei-Upload mit Vorschau, Indexierung und Folge-Events erzeugen soll

Was `upload(...)` annimmt

upload(input, options?) akzeptiert unter anderem:

normale URLs (https://…)
data:-URLs
Base64-Strings oder normalen Text
Byte-Arrays, ArrayBuffer, Uint8Array
Blob und File
Response-Objekte
gängige Wrapper-Objekte mit Dateiinhalt und Metadaten

Die hochgeladene Datei läuft dabei über denselben Upload-Weg wie andere Dateien im Produkt. Dadurch entstehen auch die üblichen Folgeeffekte wie file.uploaded-Events, Chunk-Erstellung und die normalen Datei-Zuordnungen im aktuellen Scope.

Typische Optionen

Je nach Skript kannst du in options unter anderem Dateiname, MIME-Typ oder Zielkontext mitgeben. Wenn der Dateityp oder Name aus dem Eingang nicht eindeutig erkennbar ist, solltest du diese Angaben explizit setzen.

Praktische Beispiele:

const file = await upload('https://example.com/report.pdf', {
  filename: 'report.pdf',
  mime: 'application/pdf',
});

return { hash: file.hash, url: file.url };

const csv = 'name,wert
A,10
B,20
';
const file = await upload(csv, {
  filename: 'auswertung.csv',
  mime: 'text/csv',
});

return file;

const response = await fetch('https://example.com/logo.png');
const file = await upload(response, { filename: 'logo.png' });
return { uploaded: true, hash: file.hash };

Wann `upload(...)` besser passt als `addChunks(...)`

Nutze upload(...), wenn du eine Datei normal hochladen und im CLYE-Kontext verfügbar machen willst.
Nutze addChunks(...), wenn du gezielt Wissens-Chunks schreiben oder re-indexieren willst.

Faustregel: Wenn du aus Code erst eine Datei erzeugst und diese danach wie einen normalen Upload weiterverwenden möchtest, ist upload(...) der passendere erste Schritt.

Dateisystem (`fs`)

Im Chat- und Playground-Profil steht dir das Objekt fs zur Verfügung. Im klassischen Automation-Hintergrund (ohne Chat-Kontext) ist fs kein Global — nutze dort tools.*, Events, Chunks und clye.ai, oder führe Dateizugriffe über andere Tools aus.

Chat-Kontext (typische Ordner)

Im Chat arbeitest du in einem Root wie:

/chats/<chatId>/assets (Uploads, nur lesen)
/chats/<chatId>/workspace (dein Arbeitsbereich, schreiben erlaubt)
/chats/<chatId>/workspace/out (Outputs)
/chats/<chatId>/workspace/tmp (temporär)
/chats/<chatId>/.tool-results (Tool-Artefakte)

Wichtig: Das aktuelle Arbeitsverzeichnis startet bereits in .../workspace. Nutze deshalb bevorzugt relative Pfade wie out/result.json statt workspace/out/result.json.

Verfügbare fs-Funktionen

fs.pwd(): aktuelles Verzeichnis
await fs.cd(path): Verzeichnis wechseln
await fs.ls(dir?, { glob?, limit?, offset?, withStat? }): Dateien/Ordner listen (liefert u. a. entries; das Ergebnis ist auch iterierbar)
await fs.readdir(dir?): nur Dateinamen (einfache Liste, intern über ls mit Limit)
await fs.stat(path): Metadaten zu einer Datei oder einem Ordner (type, size, mtime, isFile() / isDirectory())
await fs.exists(path)
await fs.mkdir(path, { recursive? })
await fs.rm(path, { recursive? })
await fs.readText(path, { maxBytes? })
await fs.writeText(path, content)
await fs.readJson(path)
await fs.writeJson(path, value, { pretty? })
await fs.mv(src, dst, { overwrite? })
await fs.cp(src, dst, { recursive?, overwrite? })

API im Editor durchsuchen (`help`)

Nur im Chat- und Playground-Profil (wenn fs/mcp als Globals gesetzt sind):

await help(): Überblick und Beispiele zu den Runtime-APIs
await help("addChunks"): gezielt Signaturen und Kurzbeschreibungen (u. a. fs, mcp, Chunk-Funktionen, Event-Typen)

MCP-Tools nutzen (`mcp`)

Im Chat- und Playground-Profil: Wenn in eurem Space zusätzliche Tools oder On-Demand-Server verfügbar sind, nutzt du dafür dieselben Tool-Wege wie in js_execute:

await tools.search_tool({ query: "..." }) sucht verfügbare On-Demand-Tools.
await tools.call_tool({ name: "tool_name", server: "serverName", arguments: { ... } }) ruft ein Tool gezielt auf.
Wenn der Tool-Name feststeht und direkt als Bot-Tool vorhanden ist, ist await tools.<name>({ ... }) oft die kürzeste Schreibweise.

So kannst du z. B. „Suche → Filter → Export“ automatisieren, ohne alles manuell zu klicken.

Events abfragen (lastEvent, getEvents)

Für Automationen ist es oft wichtig, Ereignisse nachzuschlagen:

await lastEvent({ type?, objectId?, causedBy? }): gibt das letzte passende Event zurück (oder null)
await getEvents({ type?, objectId?, causedBy?, limit?, cursor?, direction? }): paginierte Liste
- limit: optional, Standard 50, maximal 500
- cursor: Sequenznummer (string) des letzten Events der vorherigen Seite (wie nextCursor in der Antwort)
- direction: "desc" (Standard, neueste zuerst) oder "asc"

Das ist praktisch, um z. B. „Was ist zuletzt passiert?“ in einer Automation zu prüfen.

Wissen/Chunks bearbeiten (`addChunks`, `deleteChunk`, `deleteChunks`)

Du kannst Inhalte als Chunks in den Space schreiben oder entfernen. Die Logik entspricht grob dem Schreibpfad des RAG-Patch-Tools: bestehende Chunks mit derselben id werden überschrieben bzw. neu indexiert.

`await addChunks(chunks)`

Parameter: Array von Objekten (ChunkInput):

Feld	Bedeutung
`id`	Eindeutige ID des Chunks (wird intern in eine UUID übernommen).
`text`	Textinhalt für die Indexierung. Wenn weggelassen, wird kein neuer Text geschrieben, sondern ein Re-Index des bestehenden Chunks ausgelöst (z. B. nach Aktualisierung der `url`).
`url`	Optional: Referenz oder Binärdaten. Unterstützt u. a.: normale URL-Strings (`https://…`, interne Pfade wie `/f/…`), `data:`-URLs (werden automatisch hochgeladen und durch dauerhafte `/f/…`-Links ersetzt), `Blob` / `ArrayBuffer` / `Uint8Array` (Upload), `Response`-ähnliche Objekte (Bytes werden übernommen), sowie `{ fetch: string, init?: RequestInit, filename?: string, mime?: string }` — nur im Automation-Profil (Host lädt die URL; im Chat/Playground deaktiviert).

Wichtig für interne /f/...-Datei-URLs: Eine solche Referenz erzeugt nicht automatisch neuen Dateizugriff. CLYE AI akzeptiert interne Dateiverweise nur dann, wenn sie im jeweiligen Kontext bereits zulässig sind, zum Beispiel über einen echten Upload, eine bestehende Zuordnung, eine bestehende Freigabe oder passende Berechtigungen. Frei eingegebene Hashes, manipulierte Query-Parameter oder fremde Dateireferenzen werden nicht als neue Freigabe behandelt. Ein bereits gültiger ?key= für genau diese Datei bleibt davon unberührt und darf weiter direkt verwendet werden. Abgekürzte oder abgeschnittene CAS-Hashes gelten dabei ebenfalls nicht als gültige Dateireferenz: CLYE AI verarbeitet interne Datei-URLs nur mit vollständigem Hash und legt aus verkürzten Präfixen keine neuen Datei-Chunks an. | metadata | Optionale Schlüssel/Werte. Pflicht bei Datei-Uploads und internen /f/...-Referenzen in url: Gib Dateiname (filename oder name), MIME-Typ (mime, alternativ mimeType / mime_type) und size als Zahl mit. Fehlen diese Angaben, bricht addChunks mit einer klaren Fehlermeldung ab. | | addedAutomatically | Ob der Chunk als automatisch angelegt gilt (Standard: true). |

Wichtig bei Datei-Importen: Wenn url auf hochgeladene Bytes, ein Blob/ArrayBuffer/Uint8Array, ein Response-ähnliches Objekt, data: oder eine interne /f/...-Datei verweist, braucht addChunks die Dateimetadaten vollständig. Bei url: { fetch: "…", filename?: string, mime?: string } kann CLYE AI filename und mime aus dem url-Objekt übernehmen; size musst du weiterhin in metadata angeben.

Rückgabe: { chunkIds: string[] } — UUIDs der angelegten bzw. verarbeiteten Chunks.

`await deleteChunk(chunkId)` / `await deleteChunks(chunkIds)`

Löscht einen bzw. mehrere Chunks dauerhaft. Rückgabe jeweils mit deletedCount.

Typische Nutzung:

Ergebnisse als neue Wissenskarte/Chunk ablegen
veraltete automatische Chunks aufräumen
Inhalte nach erneuter Verarbeitung re-indexieren (text weglassen oder url/text aktualisieren)

Tools direkt aufrufen (`tools.<name>`)

Im Code gibt es ein tools-Objekt. Verfügbare Tools kannst du direkt wie eine Funktion aufrufen, zum Beispiel:

const res = await tools.rag_search({ query: "NDA", filter: undefined });

Zusätzlich kannst du Tools dynamisch über call_tool aufrufen:

const res = await tools.call_tool({
  name: 'rag_search',
  server: 'rag',
  arguments: { query: 'NDA' },
});

Für neue Skripte ist tools.call_tool({ name, server, arguments }) die empfohlene Schreibweise für dynamische Aufrufe. Bestehende Skripte mit tools.<name>(...) bleiben weiterhin gültig. Öffentliche mcp.*-Globals sowie ältere Wrapper wie tools.call_mcp(...) oder call_mcp_tool solltest du nicht mehr verwenden.

Tool-Ergebnisse kommen dabei wie im Chat direkt als structuredContent an. Wenn ein Aufruf fachlich fehlschlägt, behandeln Automation und Playground diesen Fehler jetzt als echten Tool-Fehler statt als stilles Objekt im Ergebnis. Dadurch führen Folge-Schritte mit .map(...), .filter(...) oder ähnlicher Weiterverarbeitung nicht mehr scheinbar grundlos zu Anschlussfehlern.

Für lange oder problematische Tool-Läufe gilt zusätzlich:

im Chat greift für Tool-Ausführungen ein hartes Zeitlimit mit etwas Puffer unterhalb des Request-Limits; ein Tool kann den Chat also nicht mehr unbegrenzt durch bloße Keepalive- oder Progress-Signale offenhalten
echte Fortschritte dürfen ein bestehendes Idle-Timeout weiter verschieben, das zusätzliche Gesamtlimit des Tool-Laufs läuft aber unabhängig davon weiter und endet sauber mit einem Timeout-Hinweis
wenn ein Tool keine Parameter hat, vermeidet CLYE AI bei einem Timeout Wiederholungshinweise im Stil „versuche engere Filter“ und fordert nicht einfach zum identischen erneuten Aufruf auf
sehr große Ergebnisse werden früher und konsequenter gekürzt, damit Chat, Automation und Sandbox auch bei auffällig großen Antworten stabil bleiben
bei verschachtelten js_execute-Aufrufen werden Unterergebnisse zusätzlich begrenzt; dadurch bleiben auch Tool-Ketten mit sehr großen MCP-Antworten beherrschbar

Bei Python-basierten Sandbox-Unteraufrufen bindet CLYE AI den Aufruf zusätzlich an den aktuellen Thread und den auslösenden Parent-Tool-Call. Dadurch erscheinen solche Unteraufrufe im Verlauf als verschachtelte Tool-Teile des eigentlichen Schritts, und ein gültiger Space-Zugriff allein reicht nicht mehr aus, um eine fremde Nutzer-Thread-ID in den Ablauf einzuschleusen.

Wenn dein Space aktive Automationen mit Tool-Trigger enthält, werden sie zusätzlich über den virtuellen MCP-Server automation_tools als On-Demand-Tools angeboten. Du kannst sie dadurch wie andere Space-Tools per search_tool, call_tool oder in js_execute nutzen, ohne erst einen separaten MCP-Server einzurichten.

Wichtig für normale Chats: CLYE AI lädt verbundene MCP-Server beim Start einer neuen Antwort nicht mehr unnötig breit im Voraus. Stattdessen nutzt der Chat zuerst den vorhandenen Schema-Cache. Wenn für einen verbundenen Server noch kein passendes Schema im Cache liegt, bleibt der Server für diesen Turn trotzdem verfügbar und wird bei Bedarf on-demand nachgezogen. So bleibt der erste Tool-Kontext kompakter und der Chat startet spürbar direkter, ohne dass verfügbare MCP-Tools grundsätzlich verschwinden.

Für Automationen und den Space-Playground gilt dabei: Space-MCP-Installationen werden aus dem laufenden Space aufgelöst, nicht aus dem Home-Space eines Assistenten. Das ist besonders wichtig, wenn dein persönlicher Bereich einen anderen Standard-Assistenten hat als der Arbeits-Space, in dem die Automation läuft. Space-spezifische Server wie zum Beispiel ein dort installiertes IMAP bleiben so im richtigen Kontext erreichbar.

Beispiel:

const res = await tools.call_tool({
  name: 'kunden_pruefen',
  server: 'automation_tools',
  arguments: { customerId: 'C-10024' },
});

Wichtig:

automation_tools läuft immer On-Demand und wird nicht mehr beim Chat-Start oder vor einem Lauf eager geladen
search_tool ist der normale Einstieg, wenn du den Tool-Namen erst finden oder prüfen willst
wenn du Namen und Server schon kennst, kannst du das Tool direkt über call_tool aufrufen
welche Tool-Namen dort auftauchen, hängt von euren aktivierten Automationen ab

Für die Suche nach On-Demand-Tools heißt das Discovery-Tool kanonisch search_tool und ist überall wie tools.search_tool({ ... }) erreichbar. Der frühere Name search_mcp_tool bleibt nur als veralteter Alias erhalten, damit ältere Chats und gespeicherte Aufrufe weiter funktionieren. In Suchergebnissen für das Modell werden außerdem keine iconUrl-Felder mehr mitgegeben; Symbole bleiben nur in der Oberfläche sichtbar und blähen den Modellkontext nicht unnötig auf.

Welche Tool-Namen bei euch verfügbar sind, hängt von eurem Setup (Assistent/Space) ab.

Datum, Zeit und JSON

In der Sandbox steht dir normales JavaScript zur Verfügung — typischerweise new Date(), JSON.stringify / JSON.parse und die üblichen eingebauten Objekte der QuickJS-/Node-Kompatibilitätsschicht.

Zusätzlich pflegt der Bot in den TypeScript-Deklarationen (Autocomplete im Code-Editor) und in await help("…") (nur Chat/Playground) weitere Namen wie now, addDays, formatDate, parseJson, coalesce, usw. Welche davon zur Laufzeit wirklich als globale Funktion gebunden sind, kann vom Ausführungspfad und der Bot-Version abhängen — für portable Skripte sind die Standard-APIs die zuverlässigste Wahl.

Automation-Kontext (`automation`)

Im Sandbox-Code existiert die Konstante automation mit u. a.:

id — ID der Automation (z. B. für Abfragen früherer Läufe derselben Automation)
spaceId — Space
userId / actorId — auslösender Nutzer bzw. Actor (falls gesetzt)

Modul `clye.ai` (Import)

Neben den Globals kannst du aus "clye.ai" importieren (QuickJS-Bundling im Bot):

dispatchEvent(event) — Event im Space auslösen (type, optional objectId, data, metadata, causedBy, timestamp, id für Idempotenz)
callMcpTool(serverName, toolName, input) — MCP-Tool aufrufen
getMcpResource(serverName, uri) — MCP-Ressource lesen (text/blob/Metadaten)
lastEvent / getEvents — dieselben Event-Helfer wie global (wenn du sie explizit aus dem Modul beziehen willst)

Effizient bauen: erst Code, dann LLM

Ein wichtiger Grundsatz für produktive Automationen ist: Regeln und Code zuerst, LLM nur wenn nötig.

Das bedeutet typischerweise:

zuerst prüfen, ob sich überhaupt etwas geändert hat
zuerst filtern, ob ein Treffer fachlich relevant ist
zuerst einfache Entscheidungen mit Code treffen
erst danach chat/send_message oder einen anderen LLM-basierten Schritt aufrufen

Beispiel:

Ein Postfach wird regelmäßig geprüft.
Code erkennt zuerst, ob es neue E-Mails gibt und ob darunter überhaupt interessante Nachrichten sind.
Nur diese relevanten Nachrichten werden anschließend an einen Assistenten zur Zusammenfassung oder Antwortvorbereitung gegeben.

So bleibt die Automation effizient, ohne auf Qualität zu verzichten.

dispatchEvent (fortgeschritten)

In manchen Setups kann ein Skript auch Events auslösen — per import { dispatchEvent } from "clye.ai" (siehe Abschnitt Modul clye.ai (Import) weiter oben). Wenn ihr das nutzt, macht das am besten nur in klar definierten Automationen.

Ein sehr gutes Muster ist dabei:

Code erkennt zuerst eine Änderung oder einen fachlich relevanten Fall.
Danach wird ein eigenes Event dispatcht.
Eine andere Automation reagiert auf dieses Event.

Beispiel:

Ein Code-Schritt erkennt drei geänderte Dateien.
Er dispatcht drei getrennte Events.
Weitere Automationen können diese Änderungen unabhängig voneinander verarbeiten.

Das macht Abläufe meist einfacher, retrybarer und besser erweiterbar als eine einzige große Automation mit vielen direkten Folgeschritten.

Beispiele

Beispiel: Cross-Assistant-Dateizugriff (Ordner aus einem anderen Space listen und indexieren)

Manchmal liegt ein Dateisystem-Zugriff (z. B. über einen Filesystem-Connector) in einem anderen Assistenten/Space. Wenn du trotzdem gezielt einzelne Ordner in deinem aktuellen Assistenten indexieren möchtest, kannst du MCP-Tools raumübergreifend aufrufen.

Begriffe

Base-Assistent: Assistent/Space, der Zugriff auf das Dateisystem hat.
Specific-Assistent: Assistent/Space, der nur einen Teil davon (z. B. bestimmte Ordner) nutzen bzw. indexieren soll.

Voraussetzungen

Öffne im Specific-Assistenten: Einstellungen → Berechtigungen.
Lade den Base-Assistenten ein (damit der Specific-Assistent dessen MCP-Server/Tools verwenden darf).

Optional (Best Practice): Wenn im Base-Assistenten bisher „alles“ indexiert wird, kannst du in dessen Indexierungs-Automationen die Inhalte, die künftig „spezifisch“ verarbeitet werden sollen, ausklammern (z. B. Ordner exkludieren), damit nichts doppelt läuft.

MCP-Server-ID ermitteln

Die Server-ID findest du im Specific-Assistenten unter Einstellungen → MCP-Server:

MCP-Server auswählen
Auf das Zahnrad klicken
Den Wert bei Server-Id kopieren

Tool-Aufruf im Automation-Code

Im Automation-Code rufst du das Tool über callMcpTool auf und gibst dabei zusätzlich die spaceId des Base-Assistenten an.

Parameter:

serverName: Name/ID des MCP-Servers (wie in den Einstellungen angezeigt)
toolName: Name des Tools auf diesem MCP-Server (z. B. list_directory)
input: Parameter-Objekt für das Tool
baseSpaceId: spaceId des Base-Assistenten (z. B. aus der URL des Base-Spaces)

const res = await process.env.callMcpTool(
  "Filesystem Connector",
  "list_directory",
  {
    include_hidden: false,
    path: "Vertrieb",
    recursive: true,
  },
  "123abc456-7899-56ec-bcdb-ef11801750b1"
);

Mit dem Ergebnis kannst du anschließend wie gewohnt Events dispatchen und diese in einer zweiten Automation indexieren lassen.

Empfehlung: Idempotenz beim Dispatch & Indexing

Wenn du pro Datei (oder pro gefundenem Objekt) ein Event auslöst und danach indexierst, achte darauf, dass du:

eine eindeutige objectId für das Event verwendest, damit Wiederholungen nicht zu Fehlern/Dubletten führen
beim Indexieren eine eindeutige uri verwendest

Praktisches Muster: einen Prefix voranstellen, z. B. "company-" + uri.

Beispiel: Upload lesen und Ergebnis als JSON speichern (Chat)

export default async function () {
  const input = await fs.readText("assets/input.txt");
  const lines = input.split("\n").map((l) => l.trim()).filter(Boolean);
  await fs.writeJson("out/result.json", { count: lines.length, lines });
  return { ok: true };
}

Beispiel: Tools kombinieren (Suche → Ergebnis speichern, Chat)

export default async function () {
  const result = await tools.rag_search({ query: "Vertrag", filter: undefined });
  await fs.writeJson("out/rag-result.json", result, { pretty: true });
  return { saved: true, items: result?.chunks?.length ?? 0 };
}

Kurz gesagt

Der integrierte MCP-Server JS ist der richtige Baustein, wenn ihr über reine Chat-Antworten hinaus wollt: wiederholbar, nachvollziehbar, mit Outputs, und mit der Möglichkeit, Tools und Datenverarbeitung in einem sicheren Code-Lauf zu kombinieren.

Katalog der integrierten MCP-Server

Diese Seite dokumentiert die eingebauten MCP-Server des CLYE AI möglichst vollständig. Gemeint sind die Server, die direkt im Produkt definiert werden und technisch als createVirtualMcpServer(...) entstehen.

Wichtig für die Oberfläche: Im Dialog Neuer MCP-Server bleiben Built-in-Server auch dann nutzbar, wenn zusätzliche Remote-Katalogquellen von CLYE oder Forgejo noch laden, verzögert antworten oder vorübergehend ausfallen. Der Katalog blockiert dadurch nicht mehr vollständig auf externe Quellen. Der Dialogzustand bleibt dabei auch bei Soft-Navigation oder kurzem Remount stabil. Zusätzlich lädt CLYE die externe öffentliche Registry nicht mehr schon beim ersten Öffnen des Dialogs im Hintergrund durch viele Seiten vor. Built-in-Server bleiben deshalb sofort im ersten Tab nutzbar; weitere externe Plugins werden erst nachgeladen, wenn du sie gezielt über Weitere Plugins anforderst.

Wichtig:

Nicht jeder integrierte MCP-Server ist in jedem Setup sichtbar.
Manche Server sind nur für Admins, interne Workflows oder spezielle Spaces gedacht.
Nicht jeder Server ist gleichermaßen sinnvoll als Automation Action.

Wie das mit Automation Actions zusammenhängt

Wenn ein integrierter MCP-Server echte Tools bereitstellt, erscheinen diese Tools typischerweise auch in der Aktion-Auswahl von Automationen.

Praktisch heißt das:

Der Server ist die Quelle oder Gruppe.
Das Tool ist die konkrete Automation Action.
In technischen IDs ist das meist server/tool, zum Beispiel:
- chat/send_message
- email/email_send
- event/event_dispatch
- task_management/task_create

Faustregel:

Datasource-Server liefern oft Wissen oder Suchfunktionen.
Action-Server führen eher Änderungen, Benachrichtigungen oder Prozessschritte aus.
Manche Server können beides.

Für die Auswahl im Automationsdialog siehe auch:

Schnellüberblick

Server-ID	Titel	Typischer Zweck	Als Automation Action?
`rag`	RAG	Wissenssuche in Ablage/Space	ja, oft für Recherche- oder Vorverarbeitungsschritte
`memory`	Memory	dauerhafte Notizen / Kontext	eingeschränkt, eher Spezialfall
`web`	Web	Websuche und Seiten öffnen	ja, aber mit Bedacht
`browser`	Browser	Browser-Interaktion	eher selten, nur wenn UI-Schritte nötig sind
`sharepoint`	SharePoint	Suche und Lesen in SharePoint	ja
`database`	Datenbank	SQL-Abfragen	ja
`folder`	Ordner	lokaler Ordnerzugriff	ja, wenn im Setup freigegeben
`workspace_fs`	Workspace-Dateisystem (virtuell)	Dateien lesen, patchen, löschen	ja
`space_fs`	Space-Dateisystem (Shell)	Shell-artige Dateioperationen im Space	ja
`automation`	Automation	Automationen suchen/ändern, JS/TS ausführen	ja
`chat`	Chat	Nachrichten an Chats senden	ja, sehr häufig
`task_management`	Aufgabenverwaltung	Aufgaben anlegen, suchen, aktualisieren	ja
`time_tracking`	Zeiterfassung	Zeiterfassungsberichte für sichtbare Aufgabenhierarchien, Akteure und manuelle Zeitsegmente abrufen	ja
`event`	Events	Events lesen und auslösen	ja
`email`	Email	E-Mails versenden	ja
`eml`	EML	`.eml`-Dateien parsen und eingehende E-Mails simulieren	ja
`push_notifications`	Push-Benachrichtigungen	Web-Push verschicken	ja
`template`	Template	Vorlagen abrufen und ausfüllen	ja
`form`	Form	Formulare und dokumentnahe Eingaben	eingeschränkt
`vision`	Vision	Bildanalyse	ja
`website_index`	Website-Index	Websites indexieren und bereinigen	ja
`chunk`	Chunk	Chunks indexieren oder invalidieren	ja
`skill`	Use Skills	Skills anwenden	ja
`skillAdmin`	Skill Admin Tools	Skills erstellen/suchen/patchen	eher admin-/editor-nah
`feedback`	Feedback	Feedback einreichen und eigenes Feedback lesen	ja
`feedbackAdmin`	Feedback Admin	Feedback verwalten und Insights	eher admin-/editor-nah
`mcp`	Manage local MCP servers	MCP-Server installieren, entfernen, listen	eher Admin/Setup
`custom`	Custom	eigene JS/TS-Tools	ja, für fortgeschrittene Setups
`http`	Web Request	erlaubte HTTP-Requests	ja
`parallel`	Parallel	mehrere Tools parallel ausführen	ja
`current_time`	Aktuelle Uhrzeit	Zeit/Datum	ja
`ask`	Fragen stellen	strukturierte Rückfragen an Nutzer	im Hintergrund meist unpassend
`ask_questions`	Fragen an Ersteller	Rückfragen an Content Owner	eher Chat-/Q&A-orientiert
`mdx`	MDX in Chat	UI-Komponenten im Chat rendern	nein, primär Darstellung
`bot`	Assistenten erstellen	neue Assistenten anlegen	eher Admin/Builder
`nanobana`	Nanobana	Bildgenerierung über Nanobana	ja
`admin`	Admin	Admin-Operationen	nur Admin
`test`	Test	interner Testserver	nein, nur intern
`store`	Manage local MCP servers	Store-nahe MCP-Installation	eher intern
`show_planning`	Planung anzeigen	To-do-/Planungsanzeige	eher Chat-orientiert

Wissens- und Datenserver

Diese Server sind vor allem für Suche, Lesen, Kontext und Datenzugriff gedacht.

`rag`, RAG

Wichtig für Datei-Stubs im Chat:

Wenn im Chat unter dem Feature-Flag hybridFileContext ältere oder zu große Text-, Markdown- oder Code-Anhänge nicht mehr vollständig inline mitgegeben werden, können Assistenten stattdessen einen Stub mit chunkId, hash, Datei-URL und Nachlade-Hinweisen sehen. In solchen Fällen ist rag_search der bevorzugte Weg, um den vollständigen Inhalt gezielt nachzuladen.

Praktisches Vorgehen:

bei bekannter chunkId: mit filter.partOfId oder passendem Dokument-/Chunk-Bezug arbeiten und die Treffer auf level: "child" oder "all" eingrenzen
bei bekannter hash: zuerst das passende Dokument finden und danach über partOfId in die Child-Chunks drillen
bei langen Treffermengen das nextCursor aus der vorherigen Antwort unverändert weiterverwenden, bis der benötigte Abschnitt gelesen ist
wenn statt RAG eine direkte Datei-URL besser passt, kann auch ein Datei-, URL- oder Sandbox-Tool sinnvoll sein

Zweck:

Inhalte aus Ablage, Space und Wissen finden
auf gepflegtes internes Wissen statt freies Web zugreifen

Typische Tools:

rag_search
je nach Setup zusätzliche schreibende RAG-/Chunk-Funktionen

Als Automation Action:

gut für Recherche-, Prüf- oder Anreicherungs-Schritte
oft vor chat/send_message, template/template_fill oder Export-Schritten sinnvoll

Mehr dazu:

Ablage-Suche (RAG)

`memory`, Memory

Zweck:

dauerhafte Notizen, Präferenzen und stabilen Kontext pflegen

Typische Tools:

memorize

Wichtige Rechte-Logik:

Admins können in den Space-Einstellungen optional Persönliche Memories für Nutzer erlauben aktivieren. Die Option ist standardmäßig ausgeschaltet.
Wenn die Option aktiv ist, dürfen auch Nutzer mit reinem Lesezugriff im Chat eigene private Memories anlegen oder aktualisieren.
Diese Memories bleiben strikt persönlich: Das Tool erzwingt dabei serverseitig immer isPrivate: true. Öffentliche Memories lassen sich über diesen Weg nicht anlegen.
Nutzer mit Lesezugriff dürfen nur ihre eigenen privaten Memories pflegen, nicht die von anderen Personen. Allgemeine Schreibrechte für andere Inhalte im Space entstehen dadurch nicht.

Als Automation Action:

möglich, aber gezielt einsetzen
sinnvoll, wenn ein Automation-Lauf bewusst dauerhafte Erkenntnisse speichern soll
nicht als allgemeines Protokoll missbrauchen

Mehr dazu:

Memory

`web`, Web

Zweck:

Websuche
konkrete URLs öffnen und lesen

Typische Tools:

web_search
web_open_url

Als Automation Action:

technisch möglich
sinnvoll für aktuelle externe Daten
vorsichtig bei Stabilität, Reproduzierbarkeit und Quellenschwankungen

Mehr dazu:

Web und Browser

`browser`, Browser

Zweck:

Seiten nicht nur lesen, sondern interaktiv durchgehen

Typische Tools:

browser_use

Als Automation Action:

möglich, aber eher Spezialfall
sinnvoll nur, wenn ein UI-basierter Webablauf wirklich nötig ist
weniger robust als API- oder HTTP-basierte Integrationen

`sharepoint`, SharePoint

Zweck:

Inhalte in SharePoint suchen, lesen und zusammenfassen

Typische Tools:

sharepoint_search
sharepoint_read
sharepoint_overview

Als Automation Action:

gut für Dokumentenrecherche, Inbox-/Portal-Sync, Vorprüfung und Zusammenfassungen

`database`, Datenbank

Zweck:

SQL-Abfragen auf verbundene Datenbanken

Typische Tools:

sql_query
sql_table_info
sql_tables

Als Automation Action:

sehr gut für technische Workflows
nützlich für Prüfungen, Reports, Datenanreicherung und Query-basierte Entscheidungen

`folder`, Ordner

Zweck:

lokaler Ordnerzugriff

Typische Tools:

ordner-/dateibezogene Lesezugriffe aus dem freigegebenen Kontext

Als Automation Action:

nützlich, wenn Automationen auf lokale Ordnerstrukturen zugreifen sollen
stark von eurem Setup und den Freigaben abhängig

Kommunikations- und Prozessserver

Diese Server lösen häufiger direkte Aktionen oder Folgeprozesse aus.

`chat`, Chat

Zweck:

Nachrichten an Chats senden
LLM-Antworten in bestehenden oder neuen Chats auslösen

Typische Tools:

send_message

Als Automation Action:

einer der wichtigsten Server für Automationen
ideal für HTTP-Trigger, Event-Reaktionen, externe Fälle und Assistenz-Workflows

Mehr dazu:

Aktionen

`threads`, Threads-MCP

Wichtig für neue Integrationen: Das bisherige Schreib-Tool thread_update heißt jetzt thread_patch. Ältere Aufrufe können vorübergehend weiter funktionieren, neue Doku und neue MCP-Clients sollten aber nur noch den neuen Namen verwenden.

Zweck:

einheitliche thread_*-Tools für Work Items wie Aufgaben, Projekte, Ziele, Entscheidungen und Chats
neue MCP-Anbindungen mit einem gemeinsamen Thread-Modell aufbauen

Typische Tools:

thread_get
thread_find
thread_post
thread_patch
thread_status
thread_subscribe
thread_unsubscribe
weitere thread_*-Tools je nach freigeschaltetem Work-Item-Typ

Besonders wichtig für Integrationen:

thread_subscribe und thread_unsubscribe verwalten Abonnenten direkt über das gemeinsame Thread-Modell. Beide Tools akzeptieren mehrere Einträge pro Aufruf.
Als Subscriber kannst du sowohl User-UUIDs als auch Space-UUIDs übergeben. In Tool-Kontexten sind zusätzlich die Kurzformen me und user möglich.
Die Rückgabe enthält den aktuellen Stand der Abonnenten, sodass Folgeschritte nicht erst separat nachladen müssen.
thread_patch und thread_get akzeptieren bei threadId jetzt auch dieselben tempIds aus dem laufenden Chat- oder Task-Kontext wie thread_post. Dadurch kannst du einen eben erst erzeugten Thread im nächsten Schritt direkt weiter aktualisieren oder nachladen, ohne erst die endgültige UUID aufzulösen. Wenn die tempId in einem Folgeaufruf zunächst noch nicht gefunden wird, lädt CLYE AI die gespeicherten Alias-Zuordnungen im selben Kontext noch einmal nach, bevor der Aufruf endgültig fehlschlägt.
Wenn du mehrere thread_post-Aufrufe im selben Lauf parallel anlegst, warten thread_patch und thread_get nach dem tempId-Resolve kurz auf den tatsächlich angelegten Thread. Solche Folgeaufrufe scheitern dadurch nicht mehr vorschnell mit einem Sichtbarkeits- oder Schreibfehler, nur weil die UUID schon reserviert ist, die Thread-Zeile aber noch geschrieben wird.
TempIds lassen sich dabei nur zuverlässig innerhalb eines laufenden Chat- oder Task-Kontexts auflösen. Fehlt dieser Kontext bei einem Tool-Aufruf, bricht CLYE AI mit einem klaren Hinweis auf die fehlende chatId- oder taskId-Bindung ab, statt mit einer unklaren Folgefehlermeldung.
Für Relationen in thread_patch gilt jetzt einheitlich: null und leere Listen wie [] bedeuten beim Leeren von parentId, blocks oder blockedBy dasselbe. Bestehende Kanten werden also in beiden Schreibweisen zuverlässig entfernt.
thread_patch verlangt im Unterschied zu thread_post keine Pflicht-Nachricht. Für reine Metadaten-, Relations- oder Statusänderungen musst du also kein künstliches message-Feld mitsenden.
Wenn du über thread_patch einen Status wie completed, failed oder cancelled setzt, behandelt CLYE AI das wie einen echten Abschluss. Abhängige Threads werden dadurch ebenso zuverlässig entblockt wie bei den spezialisierten Abschluss-Tools.
In den Integrations-Einstellungen ist Threads MCP jetzt die empfohlene Anbindung.
Bestehende Tasks MCP-Integrationen bleiben nutzbar, gelten aber als Legacy-Variante.
thread_post übernimmt im Threads-Modell zwei Fälle mit demselben Tool: neuen Thread anlegen (mit Pflichtfeld message) oder eine Nachricht in einen anderen bestehenden Thread posten. Ein separates thread_create gibt es dafür nicht.
Beim Anlegen liegen gemeinsame Metadaten jetzt gesammelt im optionalen Hash thread, zum Beispiel thread: { name, kind, parentId, assignee, start }. Ohne diesen Hash bleibt thread_post bewusst schlank: Pflicht sind nur message und optional tempId.
Beim Anlegen über thread_post erzeugt ein fehlendes thread.parentId immer einen Top-Level-Thread. Unterthreads entstehen nur dann, wenn du thread.parentId ausdrücklich setzt. thread.parentId akzeptiert dafür eine einzelne ID oder ein Array mehrerer Parent-Threads.
Für bestehende Threads gilt bei thread_post: Der aktuelle Thread ist bewusst gesperrt. Dort antwortest du normal im laufenden Chat; thread_post ist für neue Threads oder für Nachrichten in andere Threads gedacht.
thread_post verhält sich bei bestehenden Threads jetzt abhängig vom Ziel-Thread: Hat der Thread einen Assistenten/Bot, wartet ein weggelassenes awaitResponse weiterhin standardmäßig auf eine LLM-Antwort. Hat der Thread keinen Bot – typisch bei reinen Aufgaben-Threads – hängt CLYE AI die Nachricht bei weggelassenem awaitResponse nur an, statt mit einem Bot-Fehler hängen zu bleiben oder abzubrechen.
Setzt du bei einem bestehenden Thread awaitResponse: true ausdrücklich, bleibt das Verhalten streng: Ohne zugewiesenen Assistenten/Bot scheitert der Aufruf jetzt mit einem klaren Hinweis, dass sofortiges Warten nur mit Bot möglich ist. Mit awaitResponse: false wird die Nachricht immer nur angehängt.
Beim Anlegen eines neuen Threads läuft thread_post nur dann synchron mit Antwort, wenn du awaitResponse: true ausdrücklich setzt. Das ist der richtige Weg, um einen anderen Assistenten direkt per thread: { assignee: "<spaceId>", kind: "chat" } zu befragen.
Für solche direkten Delegationen gilt: Verwende als assignee die Space-UUID aus einem Assistenten-@-Mention. me, user oder start: true lösen diese Sofort-Antwort bewusst nicht aus.
Die Antwort des anderen Assistenten steht dann direkt im Feld answer der Tool-Antwort. Ohne explizites awaitResponse: true bleibt das Anlegen mit assignee ein Hintergrundlauf ohne sofortige Antwort.
thread_patch aktualisiert Metadaten, Relationen oder optional auch den Status, ohne dass dafür eine Pflicht-Nachricht nötig ist. Für parentId, blocks und blockedBy gilt dabei dieselbe Leerlauf-Logik: eine einzelne ID oder ein Array setzt die Relation, null oder [] entfernen bestehende Bezüge zuverlässig wieder. Solche Relation-Clears löschen dabei nicht nebenbei andere ausdrücklich gesetzte Patch-Felder wie Metadaten. Für reine Statuswechsel gibt es zusätzlich thread_status.
Felder wie priority, repeat, deadline, scheduledFor oder facets gehören jetzt ausschließlich zu thread_patch. In thread_post bleiben diese Spezialfelder bewusst außen vor.
Übergib solche Spezialfelder in thread_post auch nicht versehentlich innerhalb des Hashes thread: Unbekannte Zusatzfelder werden dort jetzt abgelehnt, statt still ignoriert zu werden. Für Werte wie repeat, deadline, scheduledFor, priority, duration, status oder facets nutze immer thread_patch.
thread_status akzeptiert nur echte Lebenszyklus-Zustände wie open, started, completed, failed, cancelled, paused oder waiting. blocked wird weiterhin automatisch aus Abhängigkeiten berechnet und nicht manuell gesetzt. Wenn du einen Thread über completed, failed oder cancelled beendest, werden abhängige Threads dabei genauso freigegeben wie bei task_complete, task_fail oder task_cancel.
Für Chats nutzen die Chat-Tools intern dieselbe UUID-Welt; threadId ist daher der bevorzugte Bezeichner, chatId bleibt als Alias kompatibel. Bei thread_find bedeutet assignee: "self" jetzt konsistent der aktive Assistent bzw. Aufrufer, nicht der menschliche Nutzer und auch nicht automatisch dessen persönlicher Assistent. Das gilt ausdrücklich auch in Chats mit deinem persönlichen Assistenten: Dort löst assignee: "self" weiter auf diesen persönlichen Assistenten auf und nicht auf dich als anfragende Person. Mit assignee: "requester" filterst du gezielt auf den aktuellen Nutzer. Die älteren Kurzformen "me" und "user" werden in den Threads-Tools nicht mehr akzeptiert.
In thread_patch kannst du assignee: null außerdem bewusst zum Entfernen einer Zuweisung verwenden.
Bei thread_find werden Status-Aliase robuster normalisiert: pending entspricht open, running entspricht started und sleeping entspricht paused. So liefern ältere oder gemischte Integrationen trotzdem den erwarteten Statusfilter.
Im Output von thread_find, thread_get und thread_patch sind Relationen jetzt klarer getrennt: parentId ist nur noch der erste Parent als Kurzform, die vollständige Parent-Liste steht in parentIds und supertasks. subtasks enthält nur echte Kinder, und blockedBy bzw. blocks bleiben reine Abhängigkeiten ohne Subtask-Kanten.
Eingebettete Relationen in supertasks, subtasks, blockedBy und blocks normalisieren Status-Aliase jetzt direkt im Output. Dort erscheinen also kanonische Werte wie open, started oder paused statt Aliasen wie pending oder running.
Läufe einer Wiederholungsserie tragen im Output zusätzlich repetitionOf mit der UUID des vorherigen Laufs. Das hilft Integrationen, einen Lauf als echte Folgeinstanz zu erkennen statt als unabhängige neue Aufgabe.
Offene Unteraufgaben mit gesetztem repetitionOf blockieren den Abschluss einer Überaufgabe nicht. Sonst würde eine wiederkehrende Unteraufgabe ihre Überaufgabe dauerhaft offen halten, obwohl die Serie normal weiterlaufen soll.
Wenn ein Thread sehr große facets enthält, kürzen thread_find, thread_get und thread_patch diese Payloads jetzt im MCP-Output. Du erkennst das an Markern wie _truncated. Für komplette Facet-Bäume solltest du dann gezielt an der Quelle nachladen, statt die gekürzte Tool-Antwort als vollständigen Zustand zu behandeln.
Wenn du mehrere thread_patch-Aufrufe parallel auf denselben Thread schickst, solltest du parentId nur mitsenden, wenn du die Parent-Beziehung wirklich ändern willst. Lässt du es bei reinen Metadaten- oder Status-Updates weg, vermeidest du versehentliche Clears oder uneinheitliche Zwischenstände.
Wenn du mehrere thread_post-Aufrufe parallel in demselben Model-Schritt erzeugst, dürfen thread.parentId, thread.blockedBy und thread.blocks dabei auch tempId-Verweise auf Geschwister-Threads verwenden. CLYE AI wartet kurz auf diese Auflösung, statt solche Beziehungen vorschnell zu verlieren.
Beim Setzen eines assignee in thread_post, thread_patch oder task_create gelten dieselben Zugriffsregeln wie beim Adressieren eines Assistenten: Explizite Agent- oder Space-UUIDs sind nur erlaubt, wenn du diesen Agenten auch wirklich ansprechen darfst. Den persönlichen Assistenten eines Nutzers darfst du nur dann direkt zuweisen, wenn du selbst genau dieser persönliche Assistent bist.
Für read_chat und vergleichbare Chat-Lesehilfen gilt: Ohne explizite ID wird automatisch der aktuelle Thread gelesen. Mit einer vollständigen UUID kannst du nicht nur klassische Chats, sondern auch Aufgaben-, Projekt-, Ziel- oder Entscheidungs-Threads laden. Akzeptiert werden dafür je nach Kontext auch Pfade wie /threads/{id} oder /tasks/{id}. Nutze dafür immer die vollständige Thread-UUID statt eines verkürzten Ordner-Suffixes unter chats/.

`task_management`, Aufgabenverwaltung

Zweck:

Aufgaben anlegen, finden, lesen, aktualisieren, löschen

Typische Tools:

task_create
task_get
task_find
task_update
task_delete
task_get_comments
task_wait
task_comment
task_complete
task_subscribe
task_unsubscribe

Besonders wichtig für Agent-Workflows:

task_create kann zusätzliche instructions für die neue Aufgabe mitgeben.
Für die Zuweisung neuer Aufgaben ist bei task_create das Feld agentId maßgeblich. Das ältere Feld botId wird beim Erstellen neuer Aufgaben nicht mehr geschrieben.
Wenn ein MCP-Client oder eine Automation bewusst keinen Assistenten setzen will, sollte dafür agentId leer bleiben oder gezielt null verwendet werden. Platzhalter wie botId: 0 sind dafür nicht vorgesehen.
task_create kann beim Erstellen auch subscribers setzen, damit Personen oder Spaces die Aufgabe direkt ab dem Anlegen abonnieren. In Tool-Kontexten sind dafür zusätzlich Kurzformen wie me oder user möglich.
Mit task_subscribe und task_unsubscribe kannst du Abonnenten einer bestehenden Aufgabe nachträglich verwalten. Beide Tools akzeptieren mehrere Subscriber pro Aufruf.
Als Subscriber unterstützen diese Tools sowohl User-UUIDs als auch Space-UUIDs. In Tool-Kontexten sind zusätzlich die Kurzformen me und user möglich.
Die Rückgabe von task_subscribe und task_unsubscribe enthält den aktuellen Stand der Abonnenten, sodass du Folgeaktionen direkt auf derselben Datenbasis aufbauen kannst.
Für subtaskOf akzeptiert task_create sowohl eine einzelne Parent-UUID als String als auch ein Array mehrerer UUIDs. Das ist besonders für Automationen wichtig, die Parameter direkt an das Tool übergeben.
Wenn ältere Daten noch parentTaskId-Werte enthalten, führt die Admin-Seite /admin/migration diese Restbestände für nutzerseitige Threads auf dieselben task_blockers-Kanten mit isSubtask über. Für neue Aufrufe schreibt task_create die Legacy-Spalte nicht mehr.
Für task_find gilt jetzt: Verwende für Abhängigkeiten weiter blockedBy und blocks. Wenn du gezielt die Aufgabenhierarchie abfragen willst, kombinierst du dieselben Felder mit isSubtask: true. Das gilt jetzt einheitlich auch für Unterchats; die ältere DB-Spalte parentTaskId ist dafür nicht mehr maßgeblich.
Offene Unteraufgaben gelten dabei nicht mehr selbst als harter Blocker der Überaufgabe. Für echte fachliche Abhängigkeiten bleiben blockedBy und blocks maßgeblich; Unteraufgaben zeigen laufende Arbeit in der Hierarchie, ohne den Parent allein deshalb auf blocked zu setzen.
Für thread_find gilt dabei die gleiche Logik im Threads-Modell: parentId findet Unterthreads zu genau diesem Parent, auch wenn derselbe Thread zusätzlich noch weitere Parents hat. Im Output ist dafür parentIds die vollständige Liste aller Parents; parentId bleibt als bequemer erster Parent erhalten.
Die einmalige Admin-Migration unterstützt dafür einen Dry-Run: Er zeigt, wie viele fehlende Unteraufgaben-Kanten angelegt und welche alten parentTaskId-Werte danach geleert würden, ohne schon Daten zu ändern.
Die älteren Filter hasSupertask und isSupertaskOf gelten nur noch als Kompatibilitätsfall. Für neue MCP- oder Tool-Aufrufe solltest du sie nicht mehr neu einplanen.
Dasselbe gilt bei task_create für blockedBy und blocks: Das Tool akzeptiert dafür entweder eine einzelne Task-UUID als String oder mehrere UUIDs als Array. Gerade MCP-Clients müssen einfache Einzelwerte dadurch nicht mehr künstlich in Listen umformen.
Wenn du bei task_create für blockedBy, blocks oder subtaskOf auf Aufgaben verweist, die nicht existieren oder in diesem Moment noch nicht sichtbar sind, bricht der gesamte Create-Lauf nicht mehr mit einem technischen Datenbankfehler ab. CLYE AI überspringt solche fehlenden Relationen stattdessen, erstellt die Aufgabe trotzdem und gibt den Hinweis als warnings zurück.
Das ist besonders wichtig bei parallelen Automationen oder MCP-Clients, die mehrere zusammenhängende Aufgaben fast gleichzeitig anlegen. Kurzzeitig noch fehlende Sibling- oder Blocker-Relationen führen dann nicht mehr zu einem schwer verständlichen SQL- oder Stacktrace-Fehler, sondern zu einer klaren fachlichen Meldung.
Wenn bei einer Unteraufgabe spaceId oder agentId fehlen, übernimmt task_create diese Werte automatisch vom Parent aus subtaskOf. Bei mehreren Parents überschreibt der letzte Parent frühere Werte; ein explizites agentId: null bleibt dabei bewusst nicht zugewiesen.
Für priority bleibt die dokumentierte Tool-Eingabe label-basiert: low, medium, high, critical oder extreme. Bestehende Automationen, die Werte ohne zusätzliche Schema-Prüfung direkt an task_create übergeben, können aber weiterhin Legacy-Zahlen wie 0 bis 4 oder String-Werte wie "2" senden. Ungültige Angaben wie Hoch, 99 oder null werden mit einer klaren Fehlermeldung abgewiesen.
task_get, task_find und task_update geben priority im MCP-Output jetzt ebenfalls als Label zurück, zum Beispiel high statt 2. Für Sortierung oder numerische Vergleiche ist zusätzlich priorityLevel mit der gespeicherten Zahl 0 bis 4 enthalten.
Bei task_find kannst du spaceId jetzt ebenfalls als einzelne UUID direkt als String übergeben. Das ist vor allem für MCP-Clients robuster, die sonst einzelne IDs fälschlich als Zeichenliste serialisieren könnten.
Mit parentContext steuerst du, ob Kontext aus der übergeordneten Aufgabe übernommen wird, zum Beispiel inherit oder none.
task_wait liefert beim Warten auf den Abschluss nicht nur einen Status, sondern je nach Verlauf auch message, result oder error zurück.
task_complete markiert eine Aufgabe direkt als erfolgreich abgeschlossen. Ein späterer automatischer Abschluss aus dem Agent-Lauf dient nur noch als Fallback, falls die Aufgabe nicht bereits explizit beendet wurde.
task_comment und explizite Abschlussnachrichten aus task_complete erscheinen als nachvollziehbare Nachrichten im zugehörigen Agent-Chat.

Als Automation Action:

sehr gut geeignet
typischer Standardserver für bestehende Aufgaben-Workflows
für neue MCP-Integrationen ist Threads MCP in der Regel die bessere erste Wahl

`time_tracking`, Zeiterfassung

Zweck:

Zeiterfassungsberichte für sichtbare Aufgaben- und Projekthierarchien abrufen
Timer auf sichtbaren Aufgaben oder Projekten starten und stoppen
Zeiten nach beteiligten Personen oder Assistenten auswerten
manuelle Zeitsegmente in Berichten mit berücksichtigen

Typische Tools:

time_tracking_status
time_tracking_timer
time_tracking_log
time_tracking_report

Als Automation Action:

gut geeignet für Reports, Auswertungen und periodische Zusammenfassungen
sinnvoll, wenn Arbeitszeiten oder erfasste Aufwände regelmäßig ausgewertet werden sollen

Wichtig für Tool-Aufrufe und MCP-Clients:

Zeitfilter wie startAt und endAt werden als ISO-8601-Strings übergeben, nicht als eingebettete Datumsobjekte
das macht das Tool-Schema JSON-Schema-kompatibel und verhindert Fehler wie „Date cannot be represented in JSON Schema“
wenn du eigene MCP-Clients, Automationen oder Integrationen baust, übergib Zeiträume daher als Stringwerte wie 2026-09-18T17:04:05Z
unbekannte oder für dich nicht sichtbare taskIds oder projectIds lassen den Bericht nicht scheitern, sondern werden still übersprungen
ohne taskIds oder projectIds kann time_tracking_report alle sichtbaren Aufgaben mit tatsächlich erfasster Zeit im gewählten Umfang selbst ermitteln
time_tracking_timer startet oder stoppt einen laufenden Timer auf einer sichtbaren Aufgabe oder einem Projekt; ohne taskId nutzt das Tool den aktuellen Thread
time_tracking_log unterstützt einzelne manuelle Einträge ebenso wie mehrere entries[] für Kalender-Übernahmen
Projektberichte können Summen nach day, week oder month gruppieren; Intervalle über Periodengrenzen werden dabei korrekt aufgeteilt
laufende Intervalle werden standardmäßig bis zum aktuellen Zeitpunkt mitgezählt und im Detail als running: true markiert

`event`, Events

Zweck:

Events lesen, auswerten und neue Events veröffentlichen

Typische Tools:

event_list
event_get
event_get_related
event_get_types
event_get_stats
event_dispatch

Als Automation Action:

sehr stark für eventgetriebene Architekturen
nützlich, wenn ein Schritt bewusst Folgeevents erzeugen soll

`eml`, EML

Zweck:

.eml-Dateien direkt parsen
den Eingang einer E-Mail wie über den normalen Inbound-Weg simulieren
für Tests, Migrationen oder technische Prüfungen dasselbe email.received-Event wie beim E-Mail-Ingress auslösen

Typische Tools:

eml_parse
eml_ingest

Wichtig:

eml_parse liest eine .eml-Datei von einer URL, einem /f/<hash>-Link oder einem CAS-Hash und gibt Header, Nachrichtentext und Anhang-Metadaten zurück, ohne ein Event zu erzeugen.
eml_ingest verarbeitet eine .eml-Datei so wie der normale Inbound-Eingang: Rohmail und Anhänge werden gespeichert und es entsteht ein email.received-Event.
Ohne zusätzliche Angaben ist der aktuelle Space das Ziel. Optional kannst du Ziel-Spaces explizit mit spaceIds setzen oder mit deriveSpaceFromTo aus der Empfängeradresse ableiten lassen.
objectId ist optional. Du kannst dafür einen beliebigen String angeben; CLYE AI wandelt ihn intern in eine UUID um.

Als Automation Action:

gut für technische Tests, reproduzierbare E-Mail-Simulationen und Import-Pipelines
sinnvoll, wenn eingehende E-Mails außerhalb des echten Posteingangs nachvollziehbar nachgestellt werden sollen

`email`, Email

Zweck:

E-Mails senden
optional mit erlaubten Empfängern, Standardempfängern und Anhängen

Typische Tools:

email_send

Als Automation Action:

sehr gut geeignet
klassischer Zielserver für Benachrichtigungen, Freigaben, Reports und externe Kommunikation

`push_notifications`, Push-Benachrichtigungen

Zweck:

Web-Push an Nutzer senden

Typische Tools:

push_notification_send

Als Automation Action:

gut für kurze, direkte Benachrichtigungen

`feedback` und `feedbackAdmin`

Zweck:

Feedback erfassen, listen, aktualisieren und auswerten

Typische Tools:

feedback_submit
feedback_list_mine
feedback_list
feedback_update
feedback_insights

Als Automation Action:

gut für Qualitäts- und Review-Schleifen
feedbackAdmin ist eher für administrative Auswertung gedacht

`template`, Template

Zweck:

Vorlagen abrufen und ausfüllen

Typische Tools:

template_get
template_fill

Als Automation Action:

sehr sinnvoll für dokumentnahe Prozesse
gut kombinierbar mit database, sharepoint, rag oder chat

`form`, Form

Zweck:

Formulare auf einer aktuell geöffneten eingebetteten Seite erkennen und gezielt befüllen
dokumentnahe Eingaben in eingebetteten Oberflächen vorbereiten

Typische Tools:

form_list zum Auflisten verfügbarer Formulare und Felder
form_fill zum Vorbereiten und Eintragen von Feldwerten in der geöffneten Formularseite

Wichtig:

form_fill wirkt nur, solange der Nutzer gerade die Seite mit dem eingebetteten Formular geöffnet hat
form_list gibt bei bekannter aktueller Seite bevorzugt nur die Formulare dieser Seite zurück; andere Seiten erscheinen nur noch als schlanke Übersicht, wenn auf der aktuellen Seite kein Formular gefunden wurde
Formulare der aktuellen Seite tragen onCurrentPage: true und sind direkt ausfüllbar
das Tool akzeptiert je nach Kontext die gemeldete Formular-ID, die Formular-URL oder die rohe Formular-ID
serverseitig wird der Vorgang zunächst nur vorbereitet; das tatsächliche Eintragen erfolgt in der eingebetteten Seite im Browser
wenn die gewählte Formular-ID zu einer anderen Seite gehört, liefert form_fill statt eines scheinbaren Erfolgs einen Hinweis auf die falsche Seite
wenn Felder im Formular nicht gefunden oder nicht unterstützt werden, können diese im Ergebnis getrennt auftauchen

Als Automation Action:

eher Spezialfall
sinnvoll, wenn ein Workflow bewusst auf strukturierte Eingaben oder Dokumenterstellung zielt

`ask`, Fragen stellen

Zweck:

dem Nutzer strukturierte Rückfragen mit Antwortoptionen stellen

Typische Tools:

ask

Als Automation Action:

technisch vorhanden
für Hintergrund-Automationen meist nicht passend
eher für interaktive Chat- oder Copilot-artige Flows geeignet

`ask_questions`, Fragen an Ersteller

Zweck:

Rückfragen an den Ersteller oder Content-Verantwortlichen notieren

Typische Tools:

rag_request_entry

Als Automation Action:

eher Spezialfall
nützlich, wenn offene Wissenslücken formal in Q&A oder Content-Pflege überführt werden sollen

Automations-, Datei- und Entwickler-Server

Diese Server sind besonders für technische Nutzer und Builder interessant.

`automation`, Automation

Zweck:

Automationen suchen, patchen, generieren oder Code ausführen

Typische Tools:

automation_search
automation_trigger_event_search
automation_patch
js_execute

Als Automation Action:

sehr mächtig
vor allem für Builder-Setups, Meta-Automationen und JS/TS-Ausführung geeignet

Mehr dazu:

Automationen und Code

`workspace_fs`, Workspace-Dateisystem (virtuell)

Zweck:

Dateien lesen, durchsuchen, patchen und löschen

Typische Tools:

glob
grep
read
applyPatch
delete

Als Automation Action:

sehr nützlich für dokumenten-, datei- oder codebezogene Workflows

`space_fs`, Space-Dateisystem (Shell)

Zweck:

shell-artige Dateioperationen im Space-Dateisystem
bearbeitbare Dateien im laufenden Chat gezielt im Canvas öffnen

Typische Tools:

fs_shell
open_in_canvas

Wichtig für Hosted Apps:

im Space-Dateisystem erscheinen Hosted Apps unter apps/<slug>/...
eine Hosted App kann entweder mit index.html starten oder direkt mit index.tsx; auch TypeScript-, React- und weitere Quell-Dateien liegen im selben App-Ordner
Änderungen an Dateien in apps/<slug>/... arbeiten weiter wie bisher über den Draft-/Publish-Ablauf
nach write_app_file und nach normalen Schreibvorgängen unter apps/<slug>/... führt CLYE AI jetzt automatisch einen Build-Check im Hintergrund aus. Wenn TypeScript-, React- oder Bundle-Fehler entstehen, erscheinen diese Hinweise direkt im Tool-Ergebnis und können im selben Bearbeitungs-Loop sofort behoben werden
write_app_file kann bestehende Dateien jetzt direkt aus einer vorhandenen CLYE-Dateireferenz übernehmen: Übergib dafür from statt Base64, zum Beispiel mit /f/<hash>/dateiname.png, einem CAS-Hash oder einer Chunk-ID. So kannst du Bilder und andere Assets in eine Hosted App übernehmen, ohne sie erst neu hochladen oder selbst kodieren zu müssen
show_app öffnet die Hosted App wieder in der Datei-Seitenleiste mit eigenem App-Tab und sichtbarer Vorschau, statt auf eine Ansicht ohne eingebettete App-Fläche zu wechseln
das gilt jetzt auch dann zuverlässig, wenn show_app, publish_app oder show_dashboard im Chat intern über einen MCP-Wrapper wie call_mcp_tool laufen; die passende Canvas-Ansicht wird dann trotzdem geöffnet
wenn dieselbe Hosted App im bereits geöffneten Canvas erneut per show_app, edit_app_file, write_app_file oder publish_app aktualisiert wird, remountet CLYE AI die Vorschau jetzt gezielt. Dadurch siehst du nach Änderungen oder nach dem Veröffentlichen nicht versehentlich weiter eine zwischengespeicherte Draft- oder Live-Ansicht
in Canvas- und Embed-Ansichten bleibt der Tool-Kanal aktiv; in geöffneten Hosted Apps können zusätzlich Element-Auswahl und ähnliche Canvas-Funktionen verfügbar sein
Canvas-Ansichten und externe /app/<domain>%2F...-Embeds laufen für Hosted Apps weiter über eigene App-Hosts; in der CLYE-Cloud bleiben das *.app.clye.ai-Hosts, in Self-Hosted-Instanzen die jeweils konfigurierte Hosted-App-Basisdomain
Draft-Vorschauen nutzen dafür ein einzelnes DNS-Label im Format {chatId}--{slug}.<hosted-app-basisdomain>; in der CLYE-Cloud ist das typischerweise {chatId}--{slug}.app.clye.ai
bestehende Draft-Links auf der bisherigen Hosted-App-Domain bleiben weiterhin erkennbar, damit ältere Vorschau-Links nicht sofort ungültig werden
ältere Preview-Hosts im Stil {chatId}.preview.{slug}.app.clye.ai werden ebenfalls weiter erkannt
sehr lange Draft-Labels weichen automatisch auf einen Preview-Pfad unter /api/hosted-app-preview/... aus
dadurch laufen Hosted Apps nicht mehr same-origin unter clye.ai; normale Sitzungs-Cookies der Plattform stehen in der App-Domain daher nicht automatisch zur Verfügung
eingebettete Hosted Apps dürfen im Canvas nur dann zusätzlich allow-same-origin in der iframe-Sandbox nutzen, wenn die Draft-Vorschau über eine eigene *.app.clye.ai-Domain läuft; beim Fallback über /api/hosted-app-preview/... bleibt diese Freigabe bewusst weg, damit keine normalen clye.ai-Cookies im iframe anliegen
auch direkt geöffnete Hosted-App-Domains unter *.app.clye.ai liefern die vollständige HTML-Seite mit korrekt eingebundenem App-Bundle
Auf der Space-Startseite öffnen Klicks auf die Hosted-App-Kachel jetzt die Plattform-Ansicht unter /app/<appId> statt direkt auf eine reine *.app.clye.ai-Vanity-URL zu wechseln
das gilt ebenso für Klicks auf die Vorschau innerhalb der Kachel und für den Tab Apps in der Ablage; dadurch bleibt die eingebettete Plattform-Ansicht mit aktivem Tool-Kanal erhalten
die /app/<appId>-Seite lädt Space, Titel und Ziel-URL aus der Hosted App und leitet Tool-Aufrufe darüber im richtigen Space-Kontext weiter
die Tool-Liste einer Hosted App auf /app/<appId> oder auf einer direkten Hosted-App-Domain ist nur noch mit gültiger Anmeldung oder aktiver Hosted-App-Bridge-Session erreichbar. Ohne Anmeldung liefert tools/list bewusst keine vollständige Tool-Übersicht mehr.
Hosted Apps lassen sich jetzt auch gezielt öffentlich teilen. Wer einen Share-Link unter /share/apps/<token> öffnet, sieht die App auch ohne Anmeldung; Installieren bleibt jedoch nur für eingeloggte Mitglieder in Spaces mit passendem Hosted-Apps-MCP möglich
öffentlich geteilte Hosted Apps auf /share/apps/<token> blenden den normalen Cookie-Banner der Plattform bewusst aus, damit diese reine Share-Ansicht nicht zusätzlich mit dem App-Inhalt konkurriert
startet eine öffentlich geteilte Hosted App über ihren Composer einen Chat, prüft CLYE AI den verifizierten Workspace-Zugriff. Ohne passenden Zugriff bleibt der Nutzer auf der Share-Seite und erhält eine verständliche Aktion zum Anmelden oder Installieren statt in einen fremden Workspace-Chat zu springen
wenn im Space ein Space-Assistent vorhanden ist, nutzen Hosted Apps auf /app/<appId> jetzt denselben Assistenten-Tool-Pfad wie im Canvas. Dadurch stehen dort dieselben Assistenten-Tools zur Verfügung wie in der Canvas-App-Ansicht.
nur wenn kein Space-Assistent vorhanden ist, bleibt der bisherige Fallback auf den Space-MCP-Katalog aktiv
installierte Builtin-Toolboxes aus dem Space, zum Beispiel die Toolbox Events mit event_list und event_get_stats, erscheinen im Fallback-Katalog weiterhin und lassen sich aus der Hosted App mit dem jeweiligen serverName aufrufen
Chat-Embeds geben dafür zusätzlich botId und chatId weiter, damit geöffnete Hosted Apps den passenden Assistenten- und Chat-Kontext übernehmen können
wenn eine Hosted App den integrierten workspace_fs-Zugriff im iframe nutzt, arbeitet dieser jetzt mit dem chatId und botId des Hosts weiter. Dateien landen dadurch im Ordner des geöffneten Chats statt versehentlich am Space-Root
tools/call mit server oder serverName läuft im Space- oder Fallback-Kontext weiter zuverlässig über den passenden MCP-Server; chatgebundene Canvas-Built-ins bleiben davon bewusst ausgenommen
externe Embed-Links unter /app/<domain>%2F... bleiben unverändert und öffnen weiter die passende externe Zieladresse
Hosted-App-Responses liefern für App-Dateien unter __clye/... jetzt die nötigen CORS-Header mit aus. Dadurch laden bundle.js und runtime.js auch dann zuverlässig, wenn die App als ES-Modul aus einer Canvas-Vorschau oder einem Preview-Host gestartet wird
Hosted Apps mit React-/TypeScript-Einstieg über index.tsx finden ihre Browser-Runtime in Production weiter zuverlässig über same-origin npm-Pfade unter __clye/npm/...: CLYE liefert dafür feste Paketversionen per Import Map aus, cached ESM-Dateien serverseitig und lädt sie bei Cache-Miss über jsDelivr mit Fallback auf unpkg nach; react-dom/client bleibt so auch ohne Bundling aus node_modules verfügbar
Tool-Aufrufe aus Hosted Apps laufen einheitlich über tools.call_tool({ name, server, arguments }) oder – bei bekannten Bot-Tools – direkt über tools.<name>({ ... }). Integrierte Server wie task_management laufen dabei zuerst über die Bot-Tools, On-Demand-Tools weiter über den Space- oder Assistenten-Kontext.
Für die Inspect-Werkzeuge geöffneter Hosted Apps läuft die eigentliche Analyse jetzt im Vanity-iframe der App selbst statt im Parent-Fenster. Werkzeuge wie screenshot_app, inspect_app_dom und inspect_app_console greifen dadurch auf denselben laufenden App-Kontext zu, den du auch siehst.
Screenshots aus screenshot_app landen in der Chat-History nur noch als normale CAS-Datei-URL statt als große Base64-Nachricht. Für den Modellkontext wird höchstens einmal eine kompakte JPEG-Variante verwendet; spätere Folge-Turns bleiben dadurch textuell und blähen den Verlauf nicht unnötig auf.
Ergebnisse aus inspect_app_dom und inspect_app_console werden für den Chat kompakt gehalten. Du bekommst also weiter verwertbare DOM- und Console-Hinweise, ohne dass sehr große Roh-Ausgaben den Chat überladen.
Tool-Ergebnisse kommen in Hosted Apps jetzt überall im gleichen Format an wie im Chat: Die App erhält direkt das nackte structuredContent des Tool-Ergebnisses, zum Beispiel { items, nextCursor }, statt einer zusätzlichen MCP-Hülle wie { content, structuredContent }.
Wenn ein Tool sehr große Ergebnisse liefert, bleiben diese für Hosted Apps vollständig erhalten. Die Kürzung für das Modell im Chat bleibt intern bestehen, wird aber nicht mehr an die App weitergereicht; Felder wie _truncated solltest du dort deshalb nicht mehr als normales Ergebnisformat einplanen.
Auch On-Demand-Server wie google-workspace oder gmail_search stehen damit wie im Assistenten-Kontext zur Verfügung, ohne zusätzliche Verfügbarkeits- oder Bestätigungsabfrage im Chat.
edit_app_file arbeitet bei Hosted Apps jetzt patch-orientiert mit old_string und new_string, statt standardmäßig ganze Dateien neu zu schreiben. Das ist besonders hilfreich, wenn du nur einen klaren Treffer austauschen und danach gezielt erneut testen oder veröffentlichen willst.
Welche MCP-Server eine Hosted App tatsächlich verwendet hat, bleibt zusätzlich in mcp_server_keys an der App gespeichert. Beim Kopieren einer App werden diese Einträge mit übernommen.
Auf der Apps-Seite im Space und in Hosted-App-Kacheln können dafür passende Connector-Icons direkt an der App erscheinen. So erkennst du schneller, welche angebundenen MCP-Server eine App im Alltag nutzt.
Wenn eine Hosted App eigene Styles per import "./styles.css" einbindet, wird das gebündelte Stylesheet jetzt auch in die HTML-Vorschau eingebunden. Dadurch erscheinen Canvas- und Embed-Vorschauen nicht mehr ungestylt.
Für Hosted Apps, die visuell zur CLYE-Oberfläche gehören sollen, steht jetzt zusätzlich der Skill hosted-app-clye-ui zur Verfügung. Nutze ihn statt des allgemeineren Skills hosted-apps, wenn deine App bewusst wie ein nativer Teil von CLYE aussehen soll.
Dieser Skill bezieht seine Theme-Tokens direkt aus der laufenden CLYE-Oberfläche statt aus einer getrennt gepflegten Farbpalette. Dadurch übernehmen eingebettete Apps Light-/Dark-Mode, theme-v3 und passende MDX-Farben konsistenter.
Änderungen am Host-Kontext wie Hell/Dunkel oder theme-v3 werden per ui/notifications/host-context-changed direkt ins iframe weitergegeben. Die Hosted App kann ihr Erscheinungsbild dadurch ohne Reload anpassen und muss dafür nicht auf den Parent-DOM zugreifen.
Für visuelle Bausteine stellt clye/clye-ui präsentationsorientierte Komponenten wie AppShell, Widget oder MetricCard bereit. Stark daten- oder tRPC-gebundene interne Karten gehören bewusst nicht zu diesem Paket.
einen kompletten App-Ordner kannst du jetzt auch direkt im Space-Dateisystem löschen: rm apps/<slug>
das Löschen ist nur für den Ersteller der Hosted App oder einen Space-Admin erlaubt
Mitglieder mit Bearbeitungsrecht im Space dürfen App-Dateien weiter ändern, aber die Hosted App nicht löschen

Wichtig für den Alltag:

open_in_canvas ist vor allem dann nützlich, wenn ein Assistent zuerst eine Datei erzeugt oder verändert und sie danach direkt im Canvas sichtbar machen soll
das ist besonders praktisch für HTML-, Markdown- oder ähnliche bearbeitbare Arbeitsdateien im Chat-Arbeitsbereich
der Aufruf öffnet die Datei als aktiven Tab in der Canvas-Seitenleiste, statt nur einen Dateilink im Chat zu zeigen
typische Upload-Bereiche oder automatisch generierte Systemordner lassen sich darüber nicht einfach beliebig im Canvas öffnen

Voraussetzungen:

der Server space_fs muss im Assistenten bzw. Space aktiviert sein
das Feature-Flag canvas muss die Canvas-Seitenleiste sichtbar machen
das Feature-Flag advancedTools steuert je nach Setup, ob space_fs in der Tool-Liste sichtbar ist

Als Automation Action:

stark für technische Dateiflüsse
mit Vorsicht einsetzen, weil es ein mächtigerer, shell-naher Zugriff ist

`custom`, Custom

Zweck:

eigene JS/TS-Tools definieren

Typische Tools:

dynamisch aus dem hinterlegten Code erzeugte Funktionen

Als Automation Action:

sehr gut für fortgeschrittene Teams
sinnvoll, wenn Standard-Tools nicht ausreichen, aber wiederverwendbare Logik gebraucht wird

`parallel`, Parallel

Zweck:

mehrere Tool-Aufrufe parallel ausführen

Typische Tools:

parallel

Als Automation Action:

gut für performance-sensitive oder voneinander unabhängige Teilaufrufe
nur nutzen, wenn Parallelität fachlich sicher ist

`http`, Web Request

Zweck:

HTTP-Requests an vorher definierte, erlaubte Endpunkte

Typische Tools:

http_request

Als Automation Action:

sehr wichtig für Integrationen
oft der direkte Weg zu Dritt- oder Inhouse-APIs

`current_time`, Aktuelle Uhrzeit

Zweck:

aktuelles Datum und aktuelle Uhrzeit beziehen

Typische Tools:

get_current_time

Als Automation Action:

hilfreich für Zeitstempel, Berichte, Datumslogik und Vorlagen

`vision`, Vision

Zweck:

Bilder oder visuelle Inhalte analysieren

Typische Tools:

vision_analyze_image

Als Automation Action:

gut für bildbezogene Prüfungen, OCR-nahe Analysen oder visuelle Vorverarbeitung

`website_index`, Website-Index

Zweck:

Websites indexieren oder bereinigen

Typische Tools:

index_website
cleanup_website_chunks

Als Automation Action:

gut für Content-Ingestion und Pflege von Webwissen

`chunk`, Chunk

Zweck:

Chunks neu erzeugen oder invalidieren

Typische Tools:

index_chunk
invalidate_chunk

Als Automation Action:

sinnvoll für RAG- und Ingestion-Workflows

`skill` und `skillAdmin`

Zweck:

Skills anwenden oder administrativ verwalten

Typische Tools:

skill_use
skill_create
skill_search
skill_get
skill_patch

Als Automation Action:

skill ist gut für standardisierte Arbeitsweisen
skillAdmin eher für Builder- und Pflegeprozesse

`show_planning`, Planung anzeigen

Zweck:

Todo-/Planungslisten im Chat sichtbar machen

Typische Tools:

todo_write

Als Automation Action:

eher Chat- und Transparenzfunktion
für Hintergrundautomationen selten die eigentliche Kernaktion

Assistenten-, UI- und Medienserver

`mdx`, MDX in Chat

Zweck:

interaktive UI-Komponenten direkt im Chat rendern

Typische Funktion:

liefert primär Instructions, keine eigentlichen Action-Tools

Als Automation Action:

nein, nicht als klassische Automation Action gedacht

Mehr dazu:

MDX im Chat

`bot`, Assistenten erstellen

Zweck:

neue Assistenten erzeugen oder bot-nahe Builder-Funktionen ausführen

Als Automation Action:

eher für Builder- und Verwaltungsflüsse
nicht typischer Standard in Fachautomationen

Mehr dazu:

Bot Father: Assistenten erstellen und verwalten

`nanobana`, Nanobana

Zweck:

Bildgenerierung über die Nanobana-API

Typische Tools:

nanobana_generate_image

Im Chat:

erzeugte Bilder werden nach der Bildgenerierung direkt im Chat angezeigt
ein Klick auf das Bild öffnet eine größere Vorschau

Als Automation Action:

gut für kreative oder mediennahe Workflows, wenn Nanobana im Setup vorhanden ist

Admin- und interne Server

Diese Server sind meist nicht für normale Endnutzer gedacht.

`mcp`, Manage local MCP servers

Zweck:

MCP-Server installieren, entfernen und auflisten

Typische Tools:

install_mcp_server
uninstall_mcp_server
list_mcp_servers

Als Automation Action:

eher Setup-/Admin-Thema

`admin`, Admin

Zweck:

administrative Operationen wie Bereinigung, Backfills oder spezielle Benachrichtigungen

Typische Tools:

clean_sandboxes
clean_chunks
send_feedback_notification
Backfill- und Wartungsaktionen für interne Datenmigrationen

Hinweise:

einzelne Admin-Aktionen laufen bewusst manuell kontrolliert und zeigen ihren Fortschritt direkt in der Oberfläche an
bei längeren Backfills muss die Admin-Seite geöffnet bleiben, damit Fortschritt, Abbruch und Abschluss sichtbar bleiben
ein Abbruch stoppt sicher nach dem aktuell bearbeiteten Eintrag; ein späterer Neustart setzt bei den verbleibenden Einträgen fort

Als Automation Action:

nur für Admin-Kontexte

`store`, Manage local MCP servers

Zweck:

MCP-Katalog im Chat durchsuchen
Space-MCP-Server direkt aus dem Chat installieren, prüfen, aktualisieren und entfernen
OAuth-Anmeldung für katalogbasierte Server im Chat anstoßen

Typische Tools:

list_mcp_catalog
install_mcp_from_catalog
list_mcp_servers
get_mcp_server
update_mcp_server
uninstall_mcp_server
start_mcp_oauth

Wichtig:

Diese Toolbox ist vor allem für Admin-, Dev- oder Test-Setups gedacht, wenn MCP-Verbindungen direkt im Chat aufgebaut oder gepflegt werden sollen.
Für manuelle Custom-URLs oder STDIO-Kommandos bleibt die klassische mcp-Toolbox beziehungsweise die Oberfläche unter MCP-Server der passendere Weg.
Wenn ein Katalog-Eintrag Pflicht-Secrets oder andere nötige Felder verlangt, nennt die Installation die fehlenden Angaben statt mit einer unklaren Teilkonfiguration weiterzulaufen.
start_mcp_oauth liefert den Link für den Browser-Login; der eigentliche Abschluss der Anmeldung passiert weiterhin außerhalb des Chats im Browser.

Als Automation Action:

eher Setup-/Admin-Thema, nicht die typische Endnutzer-Automation

`test`, Test

Zweck:

interner Testserver

Typische Tools:

timeout_test

Als Automation Action:

nein, nur intern

Welche Server zuerst relevant sind

Für die meisten produktiven Setups sind zuerst diese Server wichtig:

rag
chat
task_management
event
email
http
template
sharepoint
database
automation

Für fortgeschrittene technische Teams kommen oft dazu:

workspace_fs
space_fs
parallel
custom
website_index
vision

Kurz gesagt

Die integrierten MCP-Server sind nicht nur Chat-Zusatzfunktionen, sondern zugleich der Werkzeugkasten für Automationen. Sobald ein Server echte Tools mitbringt, tauchen diese typischerweise als mögliche Automation Actions auf. Für produktive Automationen sind besonders chat, task_management, event, email, http, template, database, sharepoint und automation relevant.

Wo du sie findest​

Wann ein integrierter MCP-Server sinnvoll ist​

Wie du sie im Alltag sinnvoll auswählst​

Typische integrierte MCP-Server​

Gute Einführungsreihenfolge​

Was du vermeiden solltest​

Kurz gesagt​

MDX im Chat​

Wofür MDX im Chat gut ist​

Wann du ihn einschalten solltest​

Wann normaler Text oft besser ist​

So fragst du sinnvoll danach​

Woran du gute Ergebnisse erkennst​

Gute erste Einsatzfälle​

Grenzen im Alltag​

Kurz gesagt​

Ablage-Suche (RAG)​

Wofür RAG im Alltag da ist​

Woran du erkennst, dass RAG hilft​

Was du dafür vorbereiten solltest​

So nutzt du RAG gut​

Zusätzlicher Suchbereich für Assistenten​

Wann RAG besser ist als Web oder Chat-Dateien​

Typische Grenzen​

Gute erste Einsatzfälle​

Kurz gesagt​

Memory​

Wofür Memory gut ist​

Wann du Memory statt normalen Chat-Kontext nutzen solltest​

Was sich gut merken lässt​

Was du besser nicht in Memory legst​

So nutzt du Memory sinnvoll​

Woran du gutes Memory erkennst​

Memory prüfen und pflegen​

Kurz gesagt​

Web und Browser​

Der einfache Unterschied​

Wann du Web nutzen solltest​

Wann Browser zusätzlich hilft​

Wann du stattdessen lieber RAG nutzt​

So formulierst du gute Anfragen​

Woran du gute Ergebnisse erkennst​

Wichtige Grenze​

Kurz gesagt​

Code ausführen (Tool js_execute, integrierter MCP-Server „JS“)​

Wann ist der JS-Server sinnvoll?​

Beziehung zu Automation Actions​

Das Tool js_execute (JS/TS in der Sandbox ausführen)​

Zwei Modi: Chat vs. Automation (wichtig)​

Dateien direkt aus js_execute hochladen (upload)​

Was upload(...) annimmt​

Typische Optionen​

Wann upload(...) besser passt als addChunks(...)​

Dateisystem (fs)​

Chat-Kontext (typische Ordner)​

Verfügbare fs-Funktionen​

API im Editor durchsuchen (help)​

MCP-Tools nutzen (mcp)​

Events abfragen (lastEvent, getEvents)​

Wissen/Chunks bearbeiten (addChunks, deleteChunk, deleteChunks)​

await addChunks(chunks)​

await deleteChunk(chunkId) / await deleteChunks(chunkIds)​

Tools direkt aufrufen (tools.<name>)​

Datum, Zeit und JSON​

Automation-Kontext (automation)​

Modul clye.ai (Import)​

Effizient bauen: erst Code, dann LLM​

dispatchEvent (fortgeschritten)​

Beispiele​

Beispiel: Cross-Assistant-Dateizugriff (Ordner aus einem anderen Space listen und indexieren)​

Begriffe​

Voraussetzungen​

MCP-Server-ID ermitteln​

Tool-Aufruf im Automation-Code​

Empfehlung: Idempotenz beim Dispatch & Indexing​

Beispiel: Upload lesen und Ergebnis als JSON speichern (Chat)​

Beispiel: Tools kombinieren (Suche → Ergebnis speichern, Chat)​

Kurz gesagt​

Katalog der integrierten MCP-Server​

Wie das mit Automation Actions zusammenhängt​

Wo du sie findest

Wann ein integrierter MCP-Server sinnvoll ist

Wie du sie im Alltag sinnvoll auswählst

Typische integrierte MCP-Server

Gute Einführungsreihenfolge

Was du vermeiden solltest

Kurz gesagt

MDX im Chat

Wofür MDX im Chat gut ist

Wann du ihn einschalten solltest

Wann normaler Text oft besser ist

So fragst du sinnvoll danach

Woran du gute Ergebnisse erkennst

Gute erste Einsatzfälle

Grenzen im Alltag

Kurz gesagt

Ablage-Suche (RAG)

Wofür RAG im Alltag da ist

Woran du erkennst, dass RAG hilft

Was du dafür vorbereiten solltest

So nutzt du RAG gut

Zusätzlicher Suchbereich für Assistenten

Wann RAG besser ist als Web oder Chat-Dateien

Typische Grenzen

Gute erste Einsatzfälle

Kurz gesagt

Memory

Wofür Memory gut ist

Wann du Memory statt normalen Chat-Kontext nutzen solltest

Was sich gut merken lässt

Was du besser nicht in Memory legst

So nutzt du Memory sinnvoll

Woran du gutes Memory erkennst

Memory prüfen und pflegen

Kurz gesagt

Web und Browser

Der einfache Unterschied

Wann du Web nutzen solltest

Wann Browser zusätzlich hilft

Wann du stattdessen lieber RAG nutzt

So formulierst du gute Anfragen

Woran du gute Ergebnisse erkennst

Wichtige Grenze

Kurz gesagt

Code ausführen (Tool `js_execute`, integrierter MCP-Server „JS“)

Wann ist der JS-Server sinnvoll?

Beziehung zu Automation Actions

Das Tool `js_execute` (JS/TS in der Sandbox ausführen)

Zwei Modi: Chat vs. Automation (wichtig)

Dateien direkt aus `js_execute` hochladen (`upload`)

Was `upload(...)` annimmt

Typische Optionen

Wann `upload(...)` besser passt als `addChunks(...)`

Dateisystem (`fs`)

Chat-Kontext (typische Ordner)

Verfügbare fs-Funktionen

API im Editor durchsuchen (`help`)

MCP-Tools nutzen (`mcp`)

Events abfragen (lastEvent, getEvents)

Wissen/Chunks bearbeiten (`addChunks`, `deleteChunk`, `deleteChunks`)

`await addChunks(chunks)`

`await deleteChunk(chunkId)` / `await deleteChunks(chunkIds)`

Tools direkt aufrufen (`tools.<name>`)

Datum, Zeit und JSON

Automation-Kontext (`automation`)

Modul `clye.ai` (Import)

Effizient bauen: erst Code, dann LLM

dispatchEvent (fortgeschritten)

Beispiele

Beispiel: Cross-Assistant-Dateizugriff (Ordner aus einem anderen Space listen und indexieren)

Begriffe

Voraussetzungen

MCP-Server-ID ermitteln

Tool-Aufruf im Automation-Code

Empfehlung: Idempotenz beim Dispatch & Indexing

Beispiel: Upload lesen und Ergebnis als JSON speichern (Chat)

Beispiel: Tools kombinieren (Suche → Ergebnis speichern, Chat)

Kurz gesagt

Katalog der integrierten MCP-Server

Wie das mit Automation Actions zusammenhängt