Zum Hauptinhalt springen

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:

Gute Einführungsreihenfolge

  1. Starte mit Ablage-Suche (RAG), wenn Wissen aus dem CLYE AI genutzt werden soll.
  2. Ergänze Memory, wenn sich ein Assistent Dinge dauerhaft merken soll.
  3. Nutze MDX im Chat, wenn Antworten visuell oder interaktiv werden sollen.
  4. Schalte Web und Browser dazu, wenn aktuelle Informationen wirklich nötig sind.
  5. 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.

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 Textvarianten
  • 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 zwei Textvarianten
  • 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. Du kannst die Inhalte vor dem Versand noch anpassen, zwischen 2–3 Stil-Varianten wie freundlich, kurz oder förmlich per Tabs wechseln, den Entwurf per Klick kopieren oder über Senden als mailto:-Link in dein Mailprogramm übernehmen. Wenn der Link sehr lang wird, weist CLYE AI zusätzlich darauf hin, dass manche Mailprogramme lange mailto:-Links abschneiden können.

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.

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:

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:

  • 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

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: … }.
    • In persönlichen Sandboxes bleibt die MCP-Session jetzt 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).

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 MCP-Server verbunden sind, kannst du sie über das Global mcp verwenden:

  • await mcp.tools() listet verfügbare Tools (Name + Beschreibung).
  • await mcp.call("serverName/toolName", { ...args }) ruft ein Tool auf. Erlaubt ist auch die Schreibweise serverName:toolName (Doppelpunkt statt Slash).

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):

FeldBedeutung
idEindeutige ID des Chunks (wird intern in eine UUID übernommen).
textTextinhalt 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).
urlOptional: 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. | 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. Ältere Formen wie tools.call_mcp('server/tool', args), call_mcp_tool, Positionsparameter oder server/tool direkt im name funktionieren aus Kompatibilitätsgründen weiter, gelten aber als veraltet.

Für die Suche nach On-Demand-MCP-Tools heißt das Discovery-Tool jetzt kanonisch search_tool. 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
  1. Öffne im Specific-Assistenten: Einstellungen → Berechtigungen.
  2. 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:

  1. MCP-Server auswählen
  2. Auf das Zahnrad klicken
  3. 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.

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-IDTitelTypischer ZweckAls Automation Action?
ragRAGWissenssuche in Ablage/Spaceja, oft für Recherche- oder Vorverarbeitungsschritte
memoryMemorydauerhafte Notizen / Kontexteingeschränkt, eher Spezialfall
webWebWebsuche und Seiten öffnenja, aber mit Bedacht
browserBrowserBrowser-Interaktioneher selten, nur wenn UI-Schritte nötig sind
sharepointSharePointSuche und Lesen in SharePointja
databaseDatenbankSQL-Abfragenja
folderOrdnerlokaler Ordnerzugriffja, wenn im Setup freigegeben
workspace_fsWorkspace-Dateisystem (virtuell)Dateien lesen, patchen, löschenja
space_fsSpace-Dateisystem (Shell)Shell-artige Dateioperationen im Spaceja
automationAutomationAutomationen suchen/ändern, JS/TS ausführenja
chatChatNachrichten an Chats sendenja, sehr häufig
task_managementAufgabenverwaltungAufgaben anlegen, suchen, aktualisierenja
eventEventsEvents lesen und auslösenja
emailEmailE-Mails versendenja
push_notificationsPush-BenachrichtigungenWeb-Push verschickenja
templateTemplateVorlagen abrufen und ausfüllenja
formFormFormulare und dokumentnahe Eingabeneingeschränkt
visionVisionBildanalyseja
website_indexWebsite-IndexWebsites indexieren und bereinigenja
chunkChunkChunks indexieren oder invalidierenja
skillUse SkillsSkills anwendenja
skillAdminSkill Admin ToolsSkills erstellen/suchen/patcheneher admin-/editor-nah
feedbackFeedbackFeedback einreichen und eigenes Feedback lesenja
feedbackAdminFeedback AdminFeedback verwalten und Insightseher admin-/editor-nah
mcpManage local MCP serversMCP-Server installieren, entfernen, listeneher Admin/Setup
customCustomeigene JS/TS-Toolsja, für fortgeschrittene Setups
httpWeb Requesterlaubte HTTP-Requestsja
parallelParallelmehrere Tools parallel ausführenja
current_timeAktuelle UhrzeitZeit/Datumja
askFragen stellenstrukturierte Rückfragen an Nutzerim Hintergrund meist unpassend
ask_questionsFragen an ErstellerRückfragen an Content Ownereher Chat-/Q&A-orientiert
mdxMDX in ChatUI-Komponenten im Chat rendernnein, primär Darstellung
botAssistenten erstellenneue Assistenten anlegeneher Admin/Builder
nanobanaNanobanaBildgenerierung über Nanobanaja
adminAdminAdmin-Operationennur Admin
testTestinterner Testservernein, nur intern
storeManage local MCP serversStore-nahe MCP-Installationeher intern
show_planningPlanung anzeigenTo-do-/Planungsanzeigeeher 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:

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:

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:

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:

threads, Threads-MCP

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_update
  • 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.

  • In den Integrations-Einstellungen ist Threads MCP jetzt die empfohlene Anbindung.

  • Bestehende Tasks MCP-Integrationen bleiben nutzbar, gelten aber als Legacy-Variante.

  • Für Chats nutzen die Chat-Tools intern dieselbe UUID-Welt; threadId ist daher der bevorzugte Bezeichner, chatId bleibt als Alias kompatibel.

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.
  • 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.
  • 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 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_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

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

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:

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
  • 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
  • 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.clye.ai-Hosts; bei Drafts wird dafür ein Preview-Host pro Chat verwendet
  • Draft-Vorschauen nutzen dafür ein einzelnes DNS-Label im Format {chatId}--{slug}.app.clye.ai; ältere Preview-Hosts im Stil {chatId}.preview.{slug}.app.clye.ai werden 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
  • 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
  • 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 akzeptieren sowohl mcp.call(serverName, toolName, args) als auch tools.call_tool({ name, server, arguments }) zuverlässig. Integrierte Server wie task_management laufen dabei zuerst über die Bot-Tools, On-Demand-MCP weiter über den Space-MCP.
  • 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.
  • 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:

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:

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.

Inhalt