MCPServer

Geltungsbereich: namespaced · Modi: catalog (gebündelt, lizenziert) · external (kostenlos)

Ein MCPServer definiert einen einzelnen Model-Context-Protocol-Server, den eine oder mehrere ChatUIs verwenden können. Einmal definieren und über spec.mcpRefs aus beliebigen ChatUIs referenzieren — der Operator bindet ihn für Sie in LibreChat (den Agents-Endpunkt) ein.

Spec

Feld	Typ	Beschreibung
mode	enum catalog | external (erforderlich)	Gebündelter Server vs. selbst betriebener Endpunkt
catalog	string	Schlüssel des gebündelten Servers (mode=catalog), z. B. websearch
external	object	Selbst betriebener Endpunkt (mode=external)
displayName	string	In LibreChat angezeigter Servername (Standard: Katalogschlüssel oder CR-Name)
serverInstructions	string	Überschreibt die an das Modell gerichtete Tool-Anleitung

external

Feld	Beschreibung
url	Der MCP-Endpunkt (z. B. http://host:8080/mcp)
type	Transport: streamable-http (Standard) oder sse
inCluster	Erzwingt die SSRF-Allowlist-Behandlung. Weglassen für automatische Erkennung anhand des Hosts (Service-DNS / private IP)
timeoutMs	Zeitlimit pro Anfrage (Standard 60000)
headersSecretRef	Secret im selben Namespace, dessen Schlüssel zu HTTP-Headern werden (per Env eingespeist, nie in die gerenderte Konfiguration geschrieben)
oauth	OAuth-2.0-Authentifizierung an einem geschützten MCP-Endpunkt (lizenziert: mcp-oauth) — siehe OAuth-Authentifizierung

external.oauth (lizenziert: mcp-oauth)

Setzen Sie genau eines von interactive oder onBehalfOf (eine Validierungsregel erzwingt dies). Ohne die mcp-oauth-Lizenz wird der MCPServer abgelehnt (MCPOAuthUnlicensed) und eine referenzierende ChatUI bleibt ungebunden.

Feld	Beschreibung
interactive	Authorization-Code- + PKCE-Flow pro Benutzer (jeder Benutzer autorisiert sich einmal beim IdP)
interactive.authorizationURL	Authorization-Endpunkt des IdP. Optional — weglassen (zusammen mit tokenURL), damit LibreChat ihn automatisch aus den Metadaten des Servers ermittelt
interactive.tokenURL	Token-Endpunkt des IdP (optional, siehe oben)
interactive.clientSecretRef	Secret im selben Namespace mit der Client-ID (client-id) und, für vertrauliche Clients, dem Client-Secret (client-secret). Per Env eingespeist, als ${…} referenziert — nie inline eingebettet. Für einen öffentlichen/PKCE-Client weglassen
interactive.scopes	Vom IdP angeforderte Scopes (durch Leerzeichen getrennt)
interactive.tokenExchangeMethod	default_post (Client-Secret im Body) oder basic_auth
onBehalfOf	Stiller On-Behalf-Of-Token-Austausch der SSO-Sitzung des Benutzers (kein Prompt)
onBehalfOf.scopes	Anzufordernde nachgelagerte Scopes (erforderlich, nicht leer), z. B. api://<client-id>/<permission>

Modi

• catalog (lizenziert: bundled-mcp-catalog) — der Operator stellt den gebündelten Server als ein gemeinsames, referenzgezähltes Release für den gesamten Cluster bereit (in navique-mcp-system) und bindet jede referenzierende ChatUI an dessen clusterinternen Service. Ohne Lizenz (Community) wird der MCPServer abgelehnt (keine Bereitstellung); eine referenzierende ChatUI wartet einfach. Der erste gebündelte Server ist websearch (Enterprise-Websuche: SearXNG + Scraping + PII + Reranking). Der Umfang wird clusterweit über PlatformConfig.spec.mcp konfiguriert (full Standard oder minimal).
• external (kostenlos / Community) — verweist auf einen selbst betriebenen MCP-Endpunkt. Clusterinterne Ziele werden automatisch erkannt und erhalten die SSRF-Allowlist von LibreChat (mcpSettings), damit private Adressen erreichbar sind.

SSRF-Allowlist (automatisch)

LibreChat blockiert MCP-Aufrufe an private/clusterinterne Adressen, sofern sie nicht freigegeben sind. Der Operator übernimmt das: Sobald ein referenzierter Server clusterintern ist, rendert er einen mcpSettings-Block auf oberster Ebene, dessen allowedDomains jede Server-Origin auflistet (eine globale Allowlist — auch öffentliche Server müssen aufgeführt sein, sonst würden sie blockiert) und dessen allowedAddresses die clusterinternen Hosts ausnimmt. Das müssen Sie nicht konfigurieren.

Beispiel — gebündelte Websuche

apiVersion: core.navique.com/v1alpha1
kind: MCPServer
metadata:
  name: websearch
  namespace: forge
spec:
  mode: catalog
  catalog: websearch
---
apiVersion: core.navique.com/v1alpha1
kind: ChatUI
metadata:
  name: forge-ui
  namespace: forge
spec:
  # … gateway/mongo/meili/secrets …
  mcpRefs:
    - { name: websearch }

Beispiel — extern (clusterintern, mit Auth)

apiVersion: core.navique.com/v1alpha1
kind: MCPServer
metadata:
  name: internal-docs
  namespace: forge
spec:
  mode: external
  external:
    url: http://docs-mcp.team.svc.cluster.local:8080/mcp
    headersSecretRef: { name: docs-mcp-auth }   # Schlüssel → HTTP-Header

OAuth-Authentifizierung (lizenziert)

Lizenziertes Feature: mcp-oauth. Binden Sie ChatUIs an MCP-Server an, die OAuth 2.0 erfordern. Zwei Modi — wählen Sie einen pro Server:

• Interaktiv (Authorization-Code + PKCE). Jeder Benutzer autorisiert sich einmal beim IdP (ein einmaliger „OAuth Required“-Prompt im Chat-Menü); Tokens werden verschlüsselt gespeichert und automatisch erneuert. Funktioniert mit jedem Anbieter. Die Client-Anmeldedaten stammen aus einem Secret und werden nie in die gerenderte Konfiguration geschrieben. Da der IdP den Browser zurück zur Oberfläche leitet, muss die ChatUI über spec.ingress erreichbar gemacht werden, damit der Callback aufgelöst wird.
• On-Behalf-Of (OBO). LibreChat tauscht das vorhandene SSO-Sitzungstoken des Benutzers stillschweigend gegen ein nachgelagertes Token — kein Prompt, kein Client-Secret. Die ChatUI muss spec.sso konfiguriert haben (das ausgetauschte Token ist die SSO-Anmeldung). Am besten für Entra-/OpenID-basierte Server.

Beispiel — interaktives OAuth

apiVersion: core.navique.com/v1alpha1
kind: MCPServer
metadata:
  name: salesforce
  namespace: forge
spec:
  mode: external
  external:
    url: https://api.salesforce.com/platform/mcp/v1/…
    oauth:
      interactive:
        authorizationURL: https://login.salesforce.com/services/oauth2/authorize
        tokenURL: https://login.salesforce.com/services/oauth2/token
        scopes: [mcp_api, refresh_token]
        clientSecretRef: { name: salesforce-mcp-oauth }  # Schlüssel: client-id, client-secret

Beispiel — On-Behalf-Of (Entra)

apiVersion: core.navique.com/v1alpha1
kind: MCPServer
metadata:
  name: graph
  namespace: forge
spec:
  mode: external
  external:
    url: https://mcp.example.com
    oauth:
      onBehalfOf:
        scopes: ["api://<client-id>/Files.Read"]
# Die referenzierende ChatUI muss spec.sso konfiguriert haben.

Hinweise

• Das Referenzieren eines beliebigen MCP-Servers aktiviert automatisch den Agents-Endpunkt von LibreChat (MCP-Tools sind nur über Agents nutzbar).
• Die native Websuche und der Code-Interpreter werden vom Operator deaktiviert, und Benutzer (auch Administratoren) können MCP-Server nicht über die Oberfläche hinzufügen oder deaktivieren — nur die Operator-Konfiguration definiert sie.

Status

{ phase, url (aufgelöster Endpunkt), transport, inCluster, serverName, conditions, observedGeneration }. Kurzname mcp.