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 derselbe Ordner in einem zweiten Tab gleichzeitig gestartet würde, verhindert CLYE eine parallele Doppelinstanz für genau diesen Ordner.
  • 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 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. 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.

Kostenpflichtige Server im Katalog erkennen​

Einige Einträge im MCP-Katalog sind kostenpflichtig. 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 kostenpflichtigen 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 es sich um einen kostenpflichtigen Server handelt.

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

Kostenpflichtigen Server anfragen​

Wenn du einen kostenpflichtigen 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 bei kostenpflichtigen Einträgen auf das Warenkorb-Icon.
  5. Klicke auf den Eintrag.
  6. In der Ansicht Plugin anfragen prüfe den vorausgefüllten Servernamen.
  7. Lies den Hinweis, dass der Server kostenpflichtig ist.
  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.

Direkte Installation durch Admins und Devs​

Wenn du Admin oder Dev bist, zeigt die Anfrage-Ansicht bei kostenpflichtigen 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.

Der typische Ablauf ist:

  1. Öffne Einstellungen → MCP-Server.
  2. Öffne den Katalog über Neuer MCP-Server.
  3. Wähle einen kostenpflichtigen Server mit Warenkorb-Icon.
  4. Prüfe in der Anfrage-Ansicht den vorausgefüllten Servernamen und den Kostenhinweis.
  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.

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.
  • 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, Nutzer-Anmeldung oder andere Spezialfälle. Für viele Katalog-Einträge reichen die Standardangaben im Hauptformular.
  • 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.
  • 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.

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

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

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