Zum Hauptinhalt springen

Chatwerkzeuge

Chat kann Modellen Werkzeugaufrufe erlauben. Bei aktivierten Werkzeugen läuft eine native Mehrfachrunde: Das Modell fordert ein Werkzeug an, Libre WebUI führt es unter Identität und Berechtigungen des Benutzers aus, das Ergebnis geht zurück, und die Schleife läuft bis zur Antwort. Pro Turn sind höchstens acht Runden mit je acht Aufrufen möglich. Stoppen bricht Modellaufruf, laufende Werkzeuge und ausstehende Freigaben ab.

Aufrufe werden als normalisierte Ereignisse (chat.tool-call.v1, chat.tool-result.v1, chat.approval.v1) über den privaten WebSocket und den dauerhaften Ereignisstrom identisch übertragen. Aktualisierung oder Neuverbindung spielt denselben Zustand wieder ab. Der abgeschlossene Turn speichert Aufrufe mit begrenzten Ergebnisvorschauen an der Assistentennachricht.

Werkzeuge aktivieren​

Sie sind standardmäßig deaktiviert. Ein Administrator öffnet sie unter Einstellungen → Benutzerverwaltung → Zugriff und Richtlinien → Werkzeugzugriff (nur Administratoren oder alle), danach aktiviert jeder Turn sie über den Schraubenschlüssel im Eingabebereich. Der Auswahldialog bietet Hauptschalter und Kontrollkästchen pro integriertem Werkzeug und Server, sodass exakt die Auswahl verwendet wird. Er kann Profilbindungen nur einschränken, nie erweitern. Private Inkognito-Chats bieten keine Werkzeuge: Ein Aufruf wirkt nach außen und kann Freigaben und Prüfprotokolle hinterlassen.

Der Schalter Werkzeugzugriff speichert sofort. Klicke ihn an oder fokussiere ihn mit Tab und schalte ihn mit Space um. Ein Wechsel des Zugriffs behält Einstellungsfenster und Scrollposition bei.

Ein Assistentenprofil (Persona) kann die Auswahl durch gebundene Server, eine Teilmenge integrierter Werkzeuge, Skills und Wissenssammlungen einschränken.

Integrierte Werkzeuge​

Chat enthält dreizehn eigene Werkzeuge (alle nur lesend außer Änderungen an Notizen und Kalendern, die den Freigabeablauf durchlaufen):

  • web_search – die vom Administrator konfigurierte Suchmaschine unter Beachtung des Zugriffsmodus.
  • search_documents – Hybridsuche in hochgeladenen Dokumenten und Wissenssammlungen, einschließlich Freigaben (Profilbindungen können Sammlungen begrenzen); jede Passage wird mit Ausschnitt und Quelle zitiert.
  • list_documents – listet Dokumente im Chatbereich mit IDs, Typen und Größen, damit das Modell auswählt.
  • read_document – liest ein begrenztes Fenster eines verfügbaren Dokuments nach ID und Offset mit Quellenstelle, um Dateien schrittweise zu untersuchen.
  • load_skill – lädt vollständige Skill-Anweisungen nach Slug; die Beschreibung enthält das Manifest aktivierter Skills, die bis zur Verwendung verzögert bleiben. Bei Begleitdateien folgt ihr Inventar.
  • read_skill_file – liest eine Begleitdatei nach Slug und relativem Pfad, sodass eine große Referenz erst beim Öffnen Kontext verbraucht.
  • list_notes – listet eigene und freigegebene Notizen mit IDs.
  • read_note – liest eine vollständige Notiz nach ID.
  • create_note – erstellt eine Notiz (Nebenwirkung, Freigabe erforderlich).
  • update_note – ersetzt Inhalt und bewahrt den vorherigen Zustand als wiederherstellbare Revision (Nebenwirkung, Freigabe erforderlich).
  • list_calendar_events – listet eigene und freigegebene Kalendertermine in einem Epochenmillisekundenbereich.
  • create_calendar_event – erstellt einen Termin (Freigabe erforderlich).
  • delete_calendar_event – löscht einen Termin nach ID (Freigabe erforderlich).

Werkzeugserver​

Administratoren registrieren externe Server unter Einstellungen → Werkzeuge (Startvorlagen füllen das Formular aus, darunter eine sichere öffentliche Demo-API):

  • OpenAPI: Eine JSON-OpenAPI-3.x-Spezifikation wird einmal abgerufen und mit SHA-256 fixiert. Jede Operation wird Werkzeug; GET gilt als nur lesend, alles andere als Nebenwirkung, bis ein Administrator es überschreibt. Die Ausführung baut den Aufruf aus der fixierten Operation; Modellargumente wählen niemals das Ziel.
  • MCP (Streamable HTTP): Die Werkzeugliste wird über JSON-RPC abgerufen und ebenso fixiert. annotations.readOnlyHint markiert nur lesenden Zugriff. stdio-MCP-Server werden bewusst nicht unterstützt; keine externen Prozesse laufen im Webprozess.

Ein geändertes Inventar gilt erst nach Aktualisierung durch einen Administrator, wodurch die Revision fortschreitet und werkzeugspezifische Überschreibungen erhalten bleiben. Die Verfügbarkeit gilt nur für Administratoren, alle Benutzer oder über Benutzer-/Gruppenfreigaben des gemeinsamen Modells.

Zugangsdaten​

Authentifizierte Server verwenden benutzerspezifische Zugangsdaten (Bearer-Token oder benannte Kopfzeile). Jedes Geheimnis wird mit zusätzlichen authentifizierten Daten verschlüsselt, die es an Benutzer und Server binden, unter Einstellungen → Werkzeuge eingegeben und nie zwischen Konten geteilt.

Interaktives OAuth (MCP)​

Ein MCP-Server kann auch jede Person für sich selbst anmelden. Registriere ihn mit dem Authentifizierungsmodus Interaktives OAuth, und Libre WebUI liest die WWW-Authenticate-Challenge, mit der der Server antwortet, folgt ihr zu den Metadaten der geschützten Ressource, dann zu den Metadaten des Autorisierungsservers, und registriert dynamisch einen Client (RFC 7591), wenn der Autorisierungsserver Registrierung anbietet. Anbieter, die Clients nicht automatisch registrieren, übernehmen eine von einem Administrator vorgegebene Client-ID und ein optionales Secret aus dem Registrierungsformular; das Secret wird zusammen mit den ermittelten Endpunkten verschlüsselt.

Jede Person drückt dann Verbinden auf der Karte des Servers und wird zum Anbieter weitergeleitet. Der Ablauf nutzt PKCE (S256) mit CSRF-State, wobei der PKCE-Verifier in einem HttpOnly-Cookie gehalten wird, das auf genau diesen einen Server begrenzt ist. Der Callback tauscht den Code serverseitig ein, speichert die Token verschlüsselt mit derselben Benutzer-und-Server-Bindung wie ein statisches Secret und schickt den Browser mit einem Statusflag zurück zur Anwendung — Zugriffs- und Refresh-Token erreichen die Seite nie. Zugriffstoken erneuern sich automatisch eine Minute vor Ablauf, einmal pro Person und Server, selbst wenn mehrere Werkzeugaufrufe gleichzeitig laufen. Ist eine Erneuerung nicht möglich, kommt der Werkzeugaufruf mit der Aufforderung zurück, die Verbindung erneut herzustellen, statt anonym zu scheitern. Trennen entfernt die Token dieser Person und lässt die Registrierung bestehen; das Löschen des Servers vergisst auch die ermittelte Konfiguration.

Ein Server, der eine unauthentifizierte Werkzeugliste verweigert, wird trotzdem registriert: Sein Bestand wird bei der ersten erfolgreichen Verbindung fixiert (und bei jeder Administrator-Aktualisierung), sodass einem Modell nie etwas angeboten wird, bevor es bekannt ist.

Ausgehende Netzwerkrichtlinie​

Jede Anfrage löst ihr Ziel selbst auf, verweigert private, Loopback- und Metadatenbereiche und fixiert die Verbindung auf die aufgelöste Adresse, damit DNS-Rebinding nicht umleitet. Weiterleitungen werden abgewiesen. Antworten sind größenbegrenzt und Aufrufe haben feste Zeitlimits. Exakte interne Hosts können über TOOLS_PRIVATE_NETWORK_ALLOWLIST (kommagetrennt) erlaubt werden; sie bleiben fixiert und begrenzt. Die Ausgabe kehrt als nicht vertrauenswürdiger Text zum Modell zurück.

Freigaben​

Nur lesende Werkzeuge laufen ohne Nachfrage. Ein Werkzeug mit Nebenwirkung pausiert und fragt: einmal, für diesen Chat, immer für dieses Werkzeug auf diesem Server oder verweigern. Entscheidungen sind dauerhaft; „immer“ überlebt Neustarts und kann widerrufen werden. Eine ausstehende Anfrage läuft nach zwei Minuten ab und erscheint dem Modell als verweigert. Verweigerung und Ablauf führen den Aufruf nie aus. Jede Entscheidung und jeder Aufruf hinterlässt ein redigiertes Sicherheitsereignis.

Beispiele​

Aktiviere zuerst den Schraubenschlüssel; jedes Beispiel ist eine normale Chatnachricht.

web_search – etwas nachschlagen​

Was hat sich in der neuesten SQLite-Version geändert? Durchsuche vor der Antwort das Web.

Das Modell ruft web_search mit etwa {"query": "SQLite latest release changelog"} auf. Die Karte zeigt empfangene Ausschnitte und die Antwort zitiert die Funde. Websuche muss konfiguriert und für das Konto erlaubt sein.

search_documents – eigene Dateien befragen​

Lade ein PDF hoch oder füge Dokumente zu einer Sammlung hinzu und frage:

Suche in meinen Dokumenten nach der Kündigungsklausel und zitiere sie exakt.

Das Modell ruft search_documents mit {"query": "termination clause"} auf und erhält gekennzeichnete Passagen zur Zuordnung.

load_skill – gespeicherten Skill anwenden​

Erstelle unter Einstellungen → Skills beispielsweise $release-notes mit deinem gewünschten Stil und frage:

Verfasse Release Notes für diesen Diff mit $release-notes.

Das Modell sieht den Skill, ruft load_skill {"slug": "release-notes"} auf und folgt den Anweisungen. $ vervollständigt Slugs automatisch.

OpenAPI-Server – etwa eine Wetter-API​

  1. Einstellungen → Werkzeuge → Server registrieren: Name Weather, Art OpenAPI, Basis-URL https://api.example-weather.dev, Spezifikations-URL https://api.example-weather.dev/openapi.json, Authentifizierung bearer.

  2. Die Spezifikation wird fixiert und Operationen erscheinen als Werkzeuge, etwa getForecast (GET, lesend) und createAlert (POST, Nebenwirkung).

  3. Jeder Benutzer speichert seinen API-Schlüssel auf der Serverkarte.

  4. Im Chat:

    Wie wird das Wetter dieses Wochenende in Montreal?

    Das Modell ruft weather__getForecast {"city": "Montreal"} auf und es läuft sofort; Lesezugriffe fragen nie.

    Warne mich, wenn es heute Nacht unter -20 fällt.

    weather__createAlert hat eine Nebenwirkung, daher zeigt der Turn Einmal erlauben, Für diesen Chat erlauben, Immer erlauben oder Verweigern. Vor der Wahl wird nichts gesendet.

Exa MCP – das Web durchsuchen und abrufen​

Wähle unter Einstellungen → Werkzeuge → Mit einer Vorlage starten den Eintrag Exa, um eine MCP-Registrierung vorauszufüllen mit:

https://mcp.exa.ai/mcp?tools=web_search_exa,web_fetch_exa

Die URL wählt web_search_exa und web_fetch_exa über den Werkzeugauswahl-Parameter von Exa. Die Vorlage nutzt keine Authentifizierung und beschränkt den Zugriff standardmäßig auf Administratoren. Prüfe das Formular und wähle Speichern, um zu verbinden und das Werkzeugverzeichnis zu pinnen. Öffnen oder Abbrechen der Vorlage kontaktiert Exa nicht. Suchanfragen und angeforderte URLs gehen an Exa, sobald diese Werkzeuge laufen.

MCP-Server – etwa ein Issue-Tracker​

  1. Einstellungen → Werkzeuge → Server registrieren: Name Issues, Art MCP, Basis-URL https://mcp.example-tracker.dev/mcp, Authentifizierung header mit X-Api-Key.

  2. Die Liste wird fixiert; als lesend markierte Werkzeuge wie search_issues laufen frei, andere wie create_issue fragen.

  3. Im Chat:

    Finde offene Issues mit "database lock" und erstelle ein neues, das das Muster zusammenfasst.

    issues__search_issues läuft sofort; issues__create_issue zeigt die exakten Argumente vor der Freigabe.

Umgebungsvariablen​

VariableWirkung
TOOLS_ACCESS_MODEFixiert die Funktion auf admins oder all-users und sperrt den Administratorschalter.
TOOLS_PRIVATE_NETWORK_ALLOWLISTExakte Hosts, die Werkzeugserver zu privaten Adressen auflösen dürfen (kommagetrennt).

Grenzen​

  • Werkzeugaufrufe laufen über WebSocket (privater Sitzungstransport ist ausgeschlossen) und den dauerhaften Generierungspfad gespeicherter Chats. Der alte REST-Streaming-Endpunkt führt die Schleife nicht aus.
  • @model-Erwähnungen in Kanälen laufen durch dieselbe Schleife gegen den Katalog des erwähnenden Mitglieds, mit einem Unterschied: Es gibt niemanden zum Nachfragen, daher wird ein wirksames Werkzeug ohne stehende Freigabe sofort abgelehnt statt zu warten. Nur lesende Werkzeuge laufen normal.
  • Work-Agenten rufen dieselben Server über dasselbe Gateway auf: nur bei Läufen mit Netzzugang, Server ohne hinterlegte Zugangsdaten werden beim Angebot herausgefiltert, wirksame Werkzeuge unterliegen den Work-Freigaben.
  • Gemini- und Agent-CLI-Modelle erhalten keine Werkzeuge; Ollama sowie OpenAI-kompatible, Responses-API- und Anthropic-Anbieter schon.
  • Interaktives OAuth gibt es nur für MCP: Ein OpenAPI-Server verwendet weiterhin statische Zugangsdaten pro Benutzer. Der Ablauf ist der Authorization-Code-Grant mit PKCE; Device-Code- und Client-Credentials-Abläufe werden nicht angeboten, und ein Autorisierungsserver, der keine Metadaten veröffentlicht (oder keinen Registrierungsendpunkt und keine administratorseitig vorgegebene Client-ID hat), kann nicht verbunden werden.
  • Ermittelte OAuth-Endpunkte müssen https sein; reines http wird nur für Loopback akzeptiert, für einen Anbieter, der während der Entwicklung auf derselben Maschine läuft.
  • Die Redirect-URI wird aus BASE_URL (oder dem ersten CORS_ORIGIN) abgeleitet, daher muss dieser Wert die Adresse sein, die der Browser tatsächlich erreicht, und er muss bei Anbietern registriert sein, die Redirect-URIs fixieren.