Zum Hauptinhalt springen

Externe 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. Externe MCP-Server erweitern den CLYE AI um zusätzliche Fähigkeiten, die nicht direkt eingebaut sind. Damit kann ein Assistent auf weitere Systeme, Dienste oder Spezialfunktionen zugreifen.

Im Unterschied zu Integrierten MCP-Servern kommen diese Verbindungen nicht aus dem Produkt selbst, sondern werden zusätzlich angebunden.

Wann externe MCP-Server sinnvoll sind​

Externe MCP-Server sind nützlich, wenn ein Assistent nicht nur mit internem Wissen oder eingebauten Werkzeugen arbeiten soll, sondern mit weiteren Diensten verbunden werden muss.

Typische Beispiele sind:

  • Kalender und Terminabstimmung
  • CRM- und Support-Systeme
  • Notizen, Wikis und Dokumentationstools
  • Dokumentenmanagement und Archive, zum Beispiel DocuWare MCP-Server
  • E-Commerce-Shops, zum Beispiel Shopware-Anbindung
  • Entwickler- und Produktivsysteme
  • spezialisierte Recherche- oder Datendienste

Der einfache Grundablauf​

Der typische Weg ist immer ähnlich:

  1. Du suchst einen passenden MCP-Server aus.
  2. Du kopierst dessen Verbindungs-URL.
  3. Du legst ihn im CLYE AI unter MCP-Server manuell an.
  4. Du meldest dich an, falls der Dienst eine Authentifizierung braucht.

Für dich als Nutzer zählt vor allem: Wenn ein Anbieter eine Streamable-HTTP-Verbindung bereitstellt, lässt sich der Dienst häufig direkt im CLYE AI anbinden.

Lokale Ordner direkt im Browser verbinden​

Wenn das Feature in eurem Setup freigeschaltet ist, kannst du lokale Ordner auch direkt im Browser als Gateway-MCP verbinden – ohne CLI und ohne separaten lokalen Wrapper. Der typische Ort dafür ist Agent Plugins.

Der Ablauf ist:

  1. Öffne den gewünschten Assistenten und gehe zu Einstellungen → Agent Plugins.
  2. Wähle die Option zum Verbinden eines lokalen Ordners.
  3. Erlaube dem Browser den Zugriff auf den gewünschten Ordner.
  4. Vergib bei Bedarf einen gut erkennbaren Namen.
  5. Prüfe danach unter Tools oder im Plugin-Eintrag, ob der Ordner als lokales Gateway verfügbar ist.

Wichtig für den Alltag:

  • Der Browser registriert den Ordner als Gateway-MCP unter einem Schlüssel nach dem Muster local-fs-<name>.
  • Bereits freigegebene Ordner können pro Browser-Tab automatisch wieder verbunden werden.
  • Wenn du nach dem Aufbau der Browser-Verbindung einen Chat mit dem aktiven Assistenten öffnest, wird die Browser-MCP-Verbindung dort in der Regel automatisch weiterverwendet.
  • Wenn der im Chat aktive Assistent in seinem Space für dich nur Leserechte hat oder nicht mehr auflösbar ist, bricht der Browser-Bootstrap nicht mehr mit einem allgemeinen Fehler ab. CLYE verbindet den Browser-Ordner dann stattdessen mit deinem persönlichen Assistenten und kann dazu im Browser einen kurzen Hinweis anzeigen.
  • Wenn derselbe Ordner in einem zweiten Tab gleichzeitig gestartet würde, verhindert CLYE eine parallele Doppelinstanz für genau diesen Ordner.
  • Datei-Aktionen aus einem verbundenen Browser-Ordner nutzen dieselbe zentrale Genehmigungsabfrage wie andere freigabepflichtige CLYE-Aktionen. Für denselben Schritt solltest du also keinen separaten zweiten Browser-Ordner-Dialog mehr bestätigen müssen.
  • Vor der Ausführung prüft CLYE zusätzlich noch einmal die tatsächlich wirksamen Berechtigungen des verbundenen Ordners. Wenn sich Freigabe oder Rechte zwischenzeitlich geändert haben, wird der Schritt nicht einfach mit veralteten Annahmen ausgeführt.
  • Die Verbindung nutzt die bestehende Anmeldung im Browser. Du musst dafür normalerweise keinen separaten Bearer-Token eintragen.
  • Bootstrap-Daten für die Browser-Anbindung werden im Browser wieder per same-origin postMessage an das Content Script des CLYE-Tabs weitergegeben.
  • Eine Weitergabe an übergeordnete Seiten außerhalb des Tabs bleibt auf erkannte Browser-Erweiterungen begrenzt, zum Beispiel mit chrome-extension:// oder moz-extension://.
  • Du kannst die Verbindung deshalb schon auf der Space-Startseite unter /spaces/{id} aufbauen; ein geöffneter Chat ist dafür nicht mehr nötig.

Falls die Browser-Anbindung im Sidepanel nicht verbindet:

  1. Öffne zuerst einen normalen CLYE-Tab, am besten direkt deine Space-Startseite unter /spaces/{id}.
  2. Prüfe, ob die Sitzung im CLYE-Tab bereits angemeldet ist.
  3. Öffne dann das Sidepanel über das Symbol der Browser-Erweiterung.
  4. Warte kurz, ob der Status von Warte… auf verbunden wechselt.
  5. Wenn der Status trotzdem nicht wechselt, öffne das Sidepanel neu und starte die Verbindung erneut aus Agent Plugins.
  6. Wenn dabei ein Hinweis erscheint, dass die Verbindung stattdessen mit deinem persönlichen Assistenten aufgebaut wurde, ist das meist ein Rechte-Thema des ursprünglich aktiven Assistenten. Du kannst den Browser-Ordner dann trotzdem weiter nutzen, nur eben über deinen persönlichen Assistenten.
  7. Wenn du danach einen Chat öffnest, sollte die Verbindung bestehen bleiben oder sich sauber neu verbinden.

Wenn du dieselbe Funktion lieber außerhalb des Browsers oder dauerhaft über die CLI betreiben willst, siehe Share-Folder.

Wenn du einen installierten Registry-Server bearbeitest​

Wenn du einen bereits installierten Server aus dem Katalog oder einer Registry erneut öffnest, lädt CLYE AI die zuletzt gespeicherten Werte wieder in die Eingabefelder. Das gilt auch für Konfigurationen, deren URL aus mehreren Platzhaltern aufgebaut wird, zum Beispiel für tenantId, siteUrl, Regions- oder Host-Werte.

Prüfe vor dem Speichern trotzdem kurz die angezeigten Werte. Maßgeblich sind immer die Felder im Bearbeitungsdialog oder im Sheet, nicht nur Beispiele oder Platzhalter aus der ursprünglichen Vorlage.

Wenn die Katalogsuche keine Treffer zeigt​

Im Sheet Neuer MCP-Server bleibt dein Klick jetzt stabil wirksam: Wenn du einen Server auswählst oder die manuelle Konfiguration öffnest, bleibt die Ansicht offen, bis der nächste Schritt wirklich angezeigt wird oder du sie selbst schließt. Auch der direkte Wechsel in die manuelle Konfiguration oder in den nächsten Installationsschritt wird dabei nicht mehr durch ein zu frühes Schließen des Dialogs verworfen. Wenn du den Dialog anschließend erneut brauchst, kannst du ihn auch direkt wieder über die Befehlspalette öffnen.

Wenn du im MCP-Katalog nach einem Server suchst und keine Treffer angezeigt werden, kannst du direkt aus diesem Leerzustand eine Plugin-Anfrage senden.

Wichtig: Das Sheet bleibt dabei auch dann nutzbar, wenn zusätzliche Katalogquellen von CLYE oder Forgejo im Hintergrund noch laden, verzögert antworten oder vorübergehend nicht erreichbar sind. Bereits verfügbare Built-in-Server und vorhandene Treffer bleiben sichtbar und installierbar.

Der Ablauf ist:

  1. Öffne Einstellungen → MCP-Server.
  2. Starte eine Suche im Katalog.
  3. Prüfe zuerst sichtbare Treffer aus Built-in, Von CLYE oder anderen bereits geladenen Bereichen.
  4. Wenn wirklich keine passenden Treffer gefunden werden, klicke auf Plugin anfragen.
  5. Du bleibst dabei im Katalog-Sheet und wechselst in die eigene Anfrage-Ansicht.
  6. Prüfe den vorgeschlagenen Suchbegriff.
  7. Beschreibe im Pflichtfeld Bemerkungen kurz deinen Anwendungsfall oder welchen Dienst dir fehlt.
  8. Achte darauf, dass die Beschreibung mindestens 10 Zeichen lang ist.
  9. Klicke auf Anfrage senden.

Die Anfrage wird intern mit deinem Namen, deiner E-Mail-Adresse, deiner aktiven Organisation und dem Auslöser Keine Katalogtreffer erfasst, damit sie besser eingeordnet und nachverfolgt werden kann. Der vorgeschlagene Suchbegriff kann dabei direkt aus der aktuellen Katalogsuche übernommen werden.

Das ist besonders sinnvoll, wenn du bereits nach einem konkreten Dienst gesucht hast, ihn aber noch nicht im Katalog findest.

Besondere Katalog-Hinweise erkennen​

Einige Einträge im MCP-Katalog sind besonders gekennzeichnet. Im Sheet Neuer MCP-Server erkennst du dadurch schon vor dem Installieren, dass ein Server nicht dem normalen Standardablauf folgt.

Typische Kennzeichnungen sind:

  • Warenkorb-Icon für kostenpflichtige oder anderweitig freigabepflichtige Server
  • Badge „Veraltet“ für Server, die nicht mehr neu verwendet werden sollen

Wichtig: Nicht jeder so gekennzeichnete Server ist einfach ein normaler externer Connector. Auch interne oder besonders freizugebende Einträge im Katalog können denselben Anfrageweg nutzen.

Kostenpflichtige oder freigabepflichtige Server im Katalog erkennen​

Einige Einträge im MCP-Katalog sind kostenpflichtig oder bewusst nur nach zusätzlicher Freigabe verfügbar. Diese Server werden im Sheet Neuer MCP-Server nicht mit einem Plus-, sondern mit einem Warenkorb-Icon gekennzeichnet.

Wichtig für den Ablauf:

  • Ein Klick auf einen so markierten Katalog-Eintrag installiert den Server nicht sofort.
  • Stattdessen wechselst du innerhalb des Katalog-Sheets in die Ansicht Plugin anfragen.
  • Der Servername wird dort automatisch vorausgefüllt.
  • Zusätzlich erscheint ein Hinweis, dass der Server nicht direkt im Standardweg hinzugefügt wird.

Für normale Nutzer:innen ist das der reguläre Weg, um Interesse an einem kostenpflichtigen oder freigabepflichtigen Server zu melden.

Kostenpflichtigen oder freigabepflichtigen Server anfragen​

Wenn du einen entsprechend markierten Server im Katalog auswählst, gehst du so vor:

  1. Öffne Einstellungen → MCP-Server.
  2. Klicke auf Neuer MCP-Server.
  3. Suche den gewünschten Server im Katalog.
  4. Achte auf Einträge mit Warenkorb-Icon.
  5. Klicke auf den Eintrag.
  6. In der Ansicht Plugin anfragen prüfe den vorausgefüllten Servernamen.
  7. Lies den Hinweis, warum der Server nicht direkt hinzugefügt wird, zum Beispiel wegen Kosten oder zusätzlicher Freigabe.
  8. Ergänze im Feld Bemerkungen kurz, wofür ihr den Server benötigt.
  9. Klicke auf Anfrage senden.

So wird die Anfrage sauber erfasst, ohne dass der Server direkt installiert wird.

Veraltete Server im Katalog erkennen​

Manche Katalog-Einträge sind zusätzlich als veraltet markiert. Du erkennst das direkt am Badge „Veraltet“ in der Kachel und in der Detailansicht.

Wichtig für den Ablauf:

  • Ein veralteter Server sollte nach Möglichkeit nicht mehr neu installiert werden.
  • In der Detailansicht erscheint deshalb ein deutlicher Warnhinweis.
  • Bereits installierte veraltete Server bleiben in der Übersicht ebenfalls als Veraltet gekennzeichnet.
  • In vorhandenen Installationen hilft dir das vor allem dabei, ältere Server gezielt zu prüfen, später abzulösen oder bewusst zu deaktivieren.

Veralteten Server trotzdem installieren​

Nur wenn du Admin oder Dev bist, kannst du einen veralteten Katalog-Server ausnahmsweise trotzdem neu installieren. Dafür ist eine ausdrückliche Bestätigung nötig.

Der Ablauf ist dann:

  1. Öffne Einstellungen → MCP-Server.
  2. Öffne den Katalog über Neuer MCP-Server.
  3. Wähle einen Eintrag mit dem Badge Veraltet.
  4. Lies den Warnhinweis in der Detailansicht vollständig.
  5. Aktiviere die Bestätigung, dass du diesen veralteten MCP-Server trotzdem installieren möchtest.
  6. Klicke erst danach auf Trotzdem installieren.

Wenn dir diese Bestätigung oder der Button nicht angezeigt wird, kannst du den veralteten Server nicht neu installieren.

Direkte Installation durch Admins und Devs​

Wenn du Admin oder Dev bist, zeigt die Anfrage-Ansicht bei entsprechend markierten Servern zusätzlich den Button Als Admin hinzufügen.

Damit kannst du den Server direkt über denselben Installationsweg wie reguläre Katalog-Einträge registrieren, ohne zuerst eine Anfrage zu senden. Das gilt nicht nur für klassische Bezahl-Plugins, sondern auch für freigabepflichtige Einträge wie den integrierten Automation-Server, wenn er im Katalog entsprechend markiert ist.

Der typische Ablauf ist:

  1. Öffne Einstellungen → MCP-Server.
  2. Öffne den Katalog über Neuer MCP-Server.
  3. Wähle einen markierten Server mit Warenkorb-Icon.
  4. Prüfe in der Anfrage-Ansicht den vorausgefüllten Servernamen und den eingeblendeten Hinweis.
  5. Klicke auf Als Admin hinzufügen.
  6. Schließe bei Bedarf anschließend noch die Anmeldung am angebundenen Dienst ab.

Wenn du diesen Button nicht siehst, kannst du den Server in der Regel nur anfragen.

Auch die bereits installierten MCP-Server sind inzwischen einheitlicher aufgebaut: Status, Tools, OAuth-Hinweise und Tests bleiben auf breiten Einstellungsseiten besser ausgerichtet. Die Bereiche Tool testen und Prompt testen erscheinen dabei weiterhin direkt im Server-Eintrag und springen nicht in eine getrennte Detailansicht. Bei installierten Servern steht zusätzlich oft ein Aktiv-Schalter direkt am Eintrag zur Verfügung. Damit kannst du ein Plugin für die KI ein- oder ausschalten, ohne die Installation selbst zu löschen.

Wichtig für den Alltag:

  • Aktiv bedeutet: Die Tools dieses Plugins stehen der KI im Kontext zur Verfügung.
  • Deaktiviert bedeutet: Der Server bleibt installiert, seine Tools werden aber nicht mehr in den KI-Kontext aufgenommen.
  • Solange ein Plugin deaktiviert ist, erscheint es auch nicht mehr im Chat-Menü Datenquellen als auswählbare Quelle.
  • Die gespeicherte Server-Konfiguration bleibt erhalten. Du kannst das Plugin später einfach wieder aktivieren.
  • Das ist besonders praktisch, wenn du ein Plugin vorübergehend aus Tests, aus einem Assistenten oder aus einem Space herausnehmen willst, ohne URL, OAuth oder andere Einstellungen neu anlegen zu müssen.
  • Ausnahme: Im separaten Bereich für Organisations-Plugins wird dieser Schalter nicht angezeigt. Diese Einträge sind dort schreibgeschützt und lassen sich in dieser Ansicht nicht direkt deaktivieren.

Die Logs eines MCP-Servers bleiben ebenfalls direkt in dieser Oberfläche nutzbar: Auch ohne vorherigen Klick in die Liste kannst du mit dem Mausrad sofort durch längere Log-Einträge scrollen.

Wichtig bei STDIO-Servern: Die reine Einstellungen- oder MCP-Server-Ansicht startet keine Sandbox im Hintergrund. Wenn ein lokaler oder gateway-basierter STDIO-Server dort noch nicht verbunden ist, zeigt CLYE deshalb Nicht verbunden statt eines dauerhaften Ladezustands. Erst ein tatsächlicher Tool-Aufruf nutzt die laufende Sandbox bzw. eine bereits registrierte Verbindung.

Beim Speichern eines STDIO-MCP-Servers prüft CLYE zusätzlich jetzt das gewählte Sandbox-Backend des Spaces. In einer klassischen Kubernetes-Sandbox muss die verwaltete Sandbox dafür laufen. Nutzt der Space dagegen OpenSandbox, reicht eine laufende Space-Sandbox allein nicht aus: Zusätzlich muss die OpenSandbox-Verbindung im Space eingerichtet und angemeldet sein, die zugehörige Runtime laufen und ihr Gateway verbunden sein. Solange diese Voraussetzungen fehlen, bleibt Speichern deaktiviert und der Hinweis erklärt dir gezielt, ob du erst die Sandbox starten, die OpenSandbox-Verbindung anmelden oder auf die Gateway-Registrierung warten musst.

Für OpenSandbox-MCP-Server läuft die OAuth-Anmeldung zusätzlich abgesichert: CLYE übergibt die Space-Zuordnung nicht mehr als frei veränderbaren OAuth-Parameter, sondern bestätigt sie serverseitig mit einem kurzlebigen Nachweis. Wenn diese sichere Bestätigung nicht gelingt, startet die Anmeldung nicht und du erhältst stattdessen einen klaren Hinweis zum erneuten Versuch.

Wenn im betroffenen Space bereits Gateway- oder STDIO-MCP-Server für diese Laufzeit vorbereitet sind, startet CLYE bei der OAuth-Anmeldung jetzt zusätzlich den nötigen CLYE-Gateway-Bootstrap in derselben OpenSandbox-Laufzeit. Dadurch steht eine neue OAuth-Sandbox nicht mehr nur als reine Code-Runtime bereit, sondern kann vorhandene lokale oder gateway-basierte MCP-Verbindungen direkt mitnutzen. Dieser Start ist nur mit Bearbeiten- oder Admin-Rechten erlaubt. Wenn der angebundene OpenSandbox-Dienst diesen Gateway-Bootstrap noch nicht unterstützt, bricht CLYE die Anmeldung bewusst mit einem klaren Hinweis ab, statt still eine unvollständige Runtime zu starten.

MCP-Katalog und Space-Server auch im Chat verwalten​

Wenn das Feature in eurem Space freigeschaltet ist, kannst du den MCP-Katalog und bereits angelegte Space-MCP-Server auch direkt im Chat verwalten. Das ist besonders hilfreich, wenn du einen Assistenten schrittweise einrichten willst, ohne dafür parallel in die Einstellungen zu wechseln.

Typische Möglichkeiten im Chat sind:

  • den MCP-Katalog durchsuchen
  • einen Server direkt aus dem Katalog installieren
  • vorhandene Space-MCP-Server auflisten und prüfen
  • eine bestehende Server-Konfiguration aktualisieren
  • einen nicht mehr benötigten Server deinstallieren
  • bei OAuth-Servern die Anmeldung über einen Auth-Link starten

Wenn ihr dafür mit einem Space-Admin-API-Key gegen den Space-MCP-Hub arbeitet, gilt dieselbe Feature-Flag-Prüfung jetzt auch für diesen API-Zugriff. Ist das zugehörige Feature für den Key-Ersteller in /admin/testing freigeschaltet, liefern typische MCP-Aufrufe wie initialize und tools/list die erwartete Antwort statt eines pauschalen 403 wegen „not enabled for this account“.

Wichtig für den Alltag:

  • Katalog-Installationen sind vor allem für Server gedacht, die bereits sauber im MCP-Katalog beschrieben sind.
  • Die externe öffentliche Registry wird nicht mehr sofort beim ersten Öffnen von Neuer MCP-Server vollständig vorab durchsucht. Zuerst siehst du wie gewohnt die direkt verfügbaren Bereiche wie Built-in oder Von CLYE/Forgejo. Weitere externe Katalogquellen lädt CLYE erst, wenn du im Dialog bewusst Weitere Plugins öffnest oder nachlädst.
  • Custom-URLs oder lokale STDIO-Setups bleiben weiterhin der richtige Weg, wenn du einen Server manuell per URL oder lokales Kommando anbinden willst.
  • Wenn in eurer Organisation die MCP-Zugriffsverwaltung aktiv ist, entscheidet eine Allow-Regel getrennt zwischen Katalog und Installieren.
  • Katalog bedeutet: Der Server ist im Hinzufügen-Dialog sichtbar.
  • Installieren bedeutet zugleich: Du darfst den Server hinzufügen und später im Chat verwenden.
  • Ohne passende Allow-Regel gilt Default Deny. Dann bleibt der Hinzufügen-Dialog leer oder ein Server ist nur sichtbar, aber nicht installierbar. Das gilt auch für Organisations-Admins.
  • Bei Nur Katalog siehst du den Server im Katalog, aber ohne Plus, Install-Button oder direkte Speicher-Möglichkeit. In der Detailansicht steht dann ausdrücklich, dass Installieren nicht erlaubt ist.
  • Wenn ein Katalog-Eintrag Pflichtfelder oder Secrets verlangt, schlägt die Installation ohne diese Angaben nicht einfach still fehl, sondern zeigt dir die fehlenden Felder an.
  • Sensible Werte wie Secrets werden bei Installieren oder Aktualisieren nicht einfach wieder im Tool-Output im Klartext zurückgegeben.
  • Unter Erweiterte Einstellungen findest du technische Optionen wie zusätzliche Datenquellen oder andere Spezialfälle. Für viele Katalog-Einträge reichen die Standardangaben im Hauptformular.
  • Bei Katalog- und Registry-Servern erscheint der Schalter „Jeder Nutzer meldet sich selbst an“ in der modernen Oberfläche wieder direkt im Hauptformular der Konfiguration. Du musst dafür also nicht erst die Erweiterten Einstellungen öffnen.
  • Bei Custom MCP reichen in vielen Fällen bereits Name und URL. On-Demand ist dabei standardmäßig aktiviert; weitere Optionen blendest du nur bei Bedarf über Erweiterte Einstellungen ein. Der Schalter „Jeder Nutzer meldet sich selbst an“ bleibt bei Custom-MCP bewusst dort.
  • Wenn du On-Demand in den Erweiterten Einstellungen bewusst ausschaltest und speicherst, bleibt dieser aus-Zustand jetzt auch erhalten. So laden passende MCP-Apps, Karten oder Diagramme nicht weiter fälschlich im On-Demand-Modus.
  • Auch bei On-Demand installierten MCP-Servern erscheinen eingebettete MCP-App-Oberflächen weiterhin direkt im Chat, wenn du sie in einem Widget, in der Task-Timeline oder in der Preview-Variante nutzt.
  • In normalen Chats mit geöffneter Canvas-Seitenleiste rechts öffnet CLYE AI eine solche MCP-App jetzt automatisch als eigenen Canvas-Tab. Im Chat selbst siehst du statt des eingebetteten Frames nur noch eine kompakte Karte mit Hinweis und Link zum erneuten Öffnen.
  • Das ist besonders für MCP-Apps wie Excalidraw hilfreich: Die App bleibt rechts interaktiv geöffnet, während du links im Chat weiterschreiben kannst. Wenn ein Server nur normalen Text zurückgibt, bleibt die Antwort wie gewohnt bei Text.
  • Bei Streamable-HTTP-Servern aus dem Katalog springt die Anmeldung nicht mehr automatisch auf OAuth. Wenn der Anbieter keine Anmeldung vorgibt, bleibt der Standard auf Keine.

Für normale Endnutzer:innen bleibt die Oberfläche unter Einstellungen → MCP-Server meist der einfachste Weg. Wenn ihr mit Organisationsregeln arbeitet, prüfe bei fehlendem Plus oder fehlendem Install-Button zuerst die Freigabe für Katalog und Installieren. Die Verwaltung im Chat ist besonders für Tests, Admin-/Dev-Workflows und geführte Setup-Schritte praktisch.

Wenn du denselben Bereich in deinem eigenen persönlichen Space öffnest, arbeitet die Verwaltung von Agent Plugins ebenfalls auf Space-Ebene. Dort verbindest und bearbeitest du also deine persönlichen Space-MCP-Server, statt sie versehentlich dem persönlichen Assistenten als eigener Assistenten-Installation zuzuordnen.

Wichtiger Unterschied: HTTP-Server und STDIO-Server​

Für Endnutzer ist vor allem diese Unterscheidung wichtig:

  • Streaming HTTP eignet sich für gehostete MCP-Server, die du nur per URL verbindest.
  • STDIO eignet sich eher für lokal oder in der Sandbox gestartete Server.

Wenn ein Server nur lokal innerhalb einer Sandbox laufen kann, brauchst du zusätzlich eine verfügbare Sandbox-Umgebung. Ohne laufende Sandbox lässt sich ein solcher Server oft nicht sinnvoll anlegen, bearbeiten oder testen.

Wenn der Server eine Anmeldung braucht​

Manche gehosteten MCP-Server verlangen zusätzlich eine Anmeldung. In diesem Fall zeigt der CLYE AI nach dem Speichern typischerweise Anmeldung erforderlich an.

Dann gehst du so vor:

  1. Klicke beim verbundenen Server auf Anmelden.
  2. Führe die Freigabe beim angebundenen Dienst durch.
  3. Kehre danach in den CLYE AI zurück.
  4. Prüfe, ob der Server jetzt erreichbar ist und seine Tools verfügbar sind.
  5. Wenn du die Anmeldung später über Abmelden oder Widerrufen entfernst, blendet CLYE den Anmelden-Bereich jetzt sofort wieder im selben Server-Eintrag ein. Du musst dafür normalerweise nicht erst manuell auf Prüfen klicken.
  6. Wenn du den Server gerade neu registriert hast, prüfe zusätzlich unter Einstellungen → MCP-Server, ob er dort sichtbar ist. Nach einem Deploy reicht dafür bei bereits verbundenen Gateways normalerweise der nächste Reconnect; ein separater Neustart der lokalen Bridge ist in diesem Fall meist nicht nötig.
  7. Wenn ein Aufruf direkt nach dem Deploy mit einem Hinweis auf fehlenden SSE-Stream oder nötige Neuverbindung scheitert, verbinde den Server einfach erneut. CLYE erkennt solche verwaisten Gateway-Sitzungen jetzt gezielt und stellt die Verbindung in der Regel ohne kompletten CLI-Neustart wieder her.
  8. Wenn die Meldung ausdrücklich auf einen getrennten Gateway-Connector hinweist, starte nicht vorschnell die Sandbox neu. In diesem Fall fehlt die Verbindung des betroffenen Connectors selbst, zum Beispiel eines lokalen oder externen Gateway-MCPs.

Bei OAuth-Servern gilt zusätzlich:

  • Die Anmeldung erfolgt immer pro Nutzer über Anmelden.
  • Trage keinen gemeinsamen Authorization-Header in der Server-Konfiguration ein.
  • Eine Anmeldung durch einen Admin oder eine andere Person gilt nicht automatisch für dich.
  • Auch wenn ein Server in den Einstellungen bereits als verbunden erscheint und seine Tools dort sichtbar sind, laufen Tool-Aufrufe im Chat bei OAuth-Servern trotzdem immer mit der Identität des aktuell angemeldeten Nutzers.
  • Ohne eingeloggten Nutzer stehen OAuth-pflichtige MCP-Server in Automationen oder Hintergrundläufen nicht pauschal nur im eigenen Space zur Verfügung. Direct-HTTP-MCP-Aufrufe funktionieren auch dann, wenn der ausführende Bot oder Worker-Mitglied im Ziel-Space ist und dort bereits eine Shared-OAuth-Anmeldung vorhanden ist, zum Beispiel beim MS-365-MCP-Server.
  • Wenn ein MCP-Server pro Nutzeranmeldung arbeitet (perUserAuth: true), braucht die Automation weiter einen zugeordneten Nutzerkontext. Fehlt dieser, zeigt CLYE eine klare Fehlermeldung statt eines unspezifischen Worker-Fehlers.
  • Wenn du in den Erweiterten Einstellungen den Schalter „Jeder Nutzer meldet sich selbst an“ wieder ausschaltest und speicherst, bleibt dieser Aus-Zustand jetzt ebenfalls erhalten. So wechselt ein bereits auf pro Nutzeranmeldung gestellter Server nicht versehentlich wieder auf den geteilten oder vorherigen Anmeldemodus zurück.
  • Katalog-Einträge können die OAuth-Felder bereits mitliefern, zum Beispiel OAuth-Client-ID, OAuth-Client-Secret, Scopes und ob die Anmeldung nutzerbezogen erfolgen soll.
  • Wenn ein Katalog-Eintrag solche OAuth-Daten vorgibt, übernimmt CLYE sie beim Anlegen automatisch in die OAuth-Konfiguration des Servers. Du musst die Werte dann nicht noch einmal separat in der manuellen OAuth-Maske eintragen.
  • Auch bei gehosteten Registry-Servern ohne vorgedruckte OAuth-Metadaten bleiben manuell eingetragene OAuth-Werte wie Client-ID, Client-Secret, Scopes und zusätzliche Authorize-Parameter jetzt in der Server-Konfiguration erhalten.
  • Das ist vor allem für Anbieter mit eigener Entra- oder OAuth-App relevant, bei denen du die OAuth-Daten selbst einträgst, obwohl der Katalog-Eintrag bereits die Remote-URL kennt.
  • Beim späteren Bearbeiten bleiben bereits gespeicherte OAuth-Werte erhalten, auch wenn sensible Felder in der Oberfläche aus Sicherheitsgründen nicht im Klartext angezeigt werden.
  • Ein typisches Beispiel ist der Dropbox-Connector: Hinterlegte Werte wie App Key und App Secret aus dem Katalog werden direkt in die CLYE-OAuth-Konfiguration übernommen.
  • Eine manuelle Client-ID ist bei OAuth-Servern nicht immer nötig. Manche Anbieter registrieren den Client erst beim Anmelden automatisch. Wenn der Server im Dialog nur zusätzliche OAuth-Parameter verlangt, kannst du die Client-ID deshalb leer lassen und trotzdem speichern.
  • Zusätzliche OAuth-Parameter in der Authorize-URL, zum Beispiel anbieterspezifische Felder für Bucket, Pfad oder Endpunkt, bleiben beim Speichern erhalten und werden beim Anmelden mitgesendet.
  • Für Microsoft-Fabric-MCP-Server setzt CLYE den OAuth-Parameter resource bewusst nicht, auch wenn bei anderen Anbietern zusätzliche Authorize-Parameter erhalten bleiben. So vermeidest du bei Entra-Anmeldungen Konflikte zwischen resource und scope.
  • Bei Microsoft Fabric hängt der nötige Scope vom Endpunkt ab: Core-MCP nutzt https://api.fabric.microsoft.com/.default, SQL-/Data-Plane-MCP stattdessen https://api.fabric.microsoft.com/Item.Execute.All und https://api.fabric.microsoft.com/Item.ReadWrite.All.
  • Die ausführliche Admin- und Endnutzer-Anleitung steht unter Microsoft Fabric MCP-Server, inklusive „Jeder Nutzer meldet sich selbst an“, Core- vs. SQL-Scopes und Troubleshooting.
  • CLYE nutzt bei modernen HTTP-MCP-Servern die vom Server veröffentlichten OAuth-Informationen automatisch, wenn diese über Discovery oder Client-Metadaten bereitgestellt werden. Du musst diese Angaben in der Regel nicht manuell zusammensuchen.
  • Bei OAuth-Anmeldungen mit Dynamic Client Registration trennt CLYE Registrierungen jetzt pro vollständiger Redirect-URI und passender OAuth-Konfiguration. So wird keine ältere Client-ID versehentlich mit einer anderen Callback-URL oder abweichenden Scopes wiederverwendet.
  • Maßgeblich ist immer die tatsächlich verwendete Callback-URL deiner geöffneten CLYE-Domain. Wenn du denselben MCP-Server über mehrere CLYE-Domains oder unterschiedliche Callback-URLs nutzt, entsteht dafür jeweils eine eigene passende Registrierung.
  • Wenn der OAuth-Anbieter nach der Registrierung eine bestätigte Redirect-URI zurückgibt, verwendet CLYE genau diese URI auch für den späteren Login und den Token-Austausch. Akzeptiert werden nur exakte Treffer sowie eine sichere Normalisierung eines abschließenden Slashs.
  • Abweichende Origins, Pfade, Query-Parameter oder Fragmente übernimmt CLYE bewusst nicht. So kann keine fremde Callback-Adresse in deinen OAuth-Flow geraten.
  • Wenn ein Anbieter bereits die neuere MCP-HTTP-Spezifikation unterstützt, erkennt CLYE den passenden Endpunkt und bevorzugt diese Verbindung automatisch. Nicht kompatible Server bleiben weiterhin über den bisherigen Verbindungsweg nutzbar.
  • Wenn ein OAuth-Server auf eine Anfrage ohne tatsächlich mitgesendeten Bearer nur mit allgemeinen 401-Meldungen wie Missing or invalid access token oder missing authorization antwortet, behandelt CLYE das nicht automatisch als endgültig widerrufene Anmeldung. Eine Re-Auth-Markierung erfolgt erst dann, wenn ein frisch gesendetes Token wirklich vom Server zurückgewiesen wird.
  • Scheitert ein Refresh-Token-Austausch einmalig in einem erkennbar terminal wirkenden Moment, versucht CLYE den Refresh bei HTTP-MCP-Servern noch genau ein zweites Mal mit kurzer Verzögerung, bevor eine bestehende OAuth-Anmeldung gelöscht wird. Das reduziert unnötige Neuverbindungen nach kurzen Server-Neustarts oder ähnlichen Übergangszuständen.

Admin-Bereich: Anmeldungen in der MCP-Übersicht beobachten​

Wenn du Admin-Rechte hast, findest du in der MCP-Übersicht zusätzlich den Tab Anmeldungen. Dort siehst du auf einen Blick, ob sich in kurzer Zeit ungewöhnlich viele MCP-Server neu anmelden oder initialisieren.

Die Ansicht hilft vor allem dabei, auffällige Wellen schneller zu erkennen, zum Beispiel nach neuen Rollouts, Konfigurationsänderungen oder externen Störungen.

Typisch in dieser Ansicht sind:

  • KPI-Karten für die letzten 1 Stunde und 24 Stunden
  • ein Vergleich mit einer 7-Tage-Baseline
  • ein Board auf Basis von mcp.server.initialized-Events

So kannst du schneller einschätzen, ob die aktuelle Zahl der Anmeldungen noch im üblichen Rahmen liegt oder vom Normalwert abweicht.

Für Endnutzer:innen ändert sich dadurch nichts an der eigentlichen Anmeldung. Der Tab dient nur der Beobachtung und Einordnung im Admin-Bereich.

Du musst dafür in der Regel nichts lokal installieren.

Woran du eine gute Auswahl erkennst​

  • der Dienst löst ein klares Problem im Alltag
  • die verfügbaren Tools passen wirklich zum Einsatzzweck
  • die Anmeldung ist nachvollziehbar
  • nur die wirklich nötigen Systeme werden verbunden

Wenn du neu damit startest, binde zuerst nur einen einzelnen externen MCP-Server an und prüfe, ob er im Alltag wirklich Mehrwert liefert.

Was du vermeiden solltest​

  • mehrere neue externe Server gleichzeitig hinzufügen
  • Systeme ohne klaren fachlichen Nutzen verbinden
  • eingebaute und externe MCP-Server gedanklich vermischen
  • unnötige Zusatzkonfiguration eintragen, wenn die URL allein schon reicht

Kurz gesagt​

Externe MCP-Server verbinden den CLYE AI mit zusätzlichen Diensten außerhalb des Produkts. Für gehostete MCP-Server reicht meist: passende URL kopieren, im CLYE AI unter MCP-Server manuell als Streaming HTTP anlegen, speichern und bei Bedarf anmelden.

MCP-Tool-Calls: Nutzerkontext per _meta​

Assistenten können optional den aktuellen Nutzerkontext an MCP-Tool-Calls weitergeben.

Wenn die Option aktiviert ist, wird bei MCP tools/call Requests folgendes Feld ergänzt:

{
  "_meta": {
    "clye.ai/user": {
      "id": "user-id",
      "email": "user@example.com",
      "personalSpaceId": "space-id"
    }
  }
}

Einstellung​

Die Option ist pro Assistent konfigurierbar:

  • Einstellung: Nutzerkontext an MCP-Tools senden
  • Ort: Assistenten-Einstellungen → Advanced
  • Config-Feld: sendUserMetaToMcpTools
  • Standardwert: false

Damit ist das Verhalten opt-in und bleibt für neue Assistenten standardmäßig deaktiviert.

Inhalt​

ctx.user enthält den Nutzerkontext des aktuell ausführenden Requests:

{
  id?: string;
  email?: string;
  personalSpaceId?: string;
}

Felder:

  • id: interne User-ID des Nutzers
  • email: E-Mail-Adresse des Nutzers, falls verfügbar
  • personalSpaceId: persönliche Space-ID des Nutzers; häufig relevant für Berechtigungen, Actor-Zuordnung und Auditing

Alle Felder sind optional, da MCP-Calls auch aus Kontexten ohne vollständigen Nutzerkontext kommen können.

Verhalten​

Wenn sendUserMetaToMcpTools aktiviert ist:

  • ctx.user wird als _meta["clye.ai/user"] an MCP tools/call Requests angehängt.
  • Das gilt für normale MCP-Tool-Calls, direkte HTTP/SSE-MCP-Clients und Progress-Streaming-Calls.
  • Bereits vorhandene _meta-Werte (z. B. progressToken) bleiben erhalten.

Wenn die Option deaktiviert ist:

  • Es werden keine Nutzerdaten in _meta["clye.ai/user"] mitgeschickt.
  • Technische _meta-Werte wie progressToken können weiterhin vorhanden sein.

Wofür MCP-Server das nutzen können​

MCP-Server können den Nutzerkontext verwenden für:

  • nutzerbezogene Berechtigungsprüfung
  • Audit-Logs und Nachvollziehbarkeit
  • Mandanten-/Space-Zuordnung über personalSpaceId
  • nutzerspezifische Datenfilter
  • personalisierte Antworten oder Aktionen

Datenschutz-Hinweis​

email ist personenbezogen. MCP-Server sollten diesen Wert nur speichern oder weiterverarbeiten, wenn er wirklich benötigt wird. Für technische Zuordnung ist meist personalSpaceId ausreichend.

Inhalt